The following testcase fails when compiled without specifying the explicit include path for the decimal/decimal header: decimal.cpp --------------------------------------------------------------------------- #include <decimal> using namespace std::decimal; int main() { decimal64 d64; decimal128 d128; /* extendddtd2 */ d128 = d64; return 0; } $ /opt/at5.0/bin/g++ -m64 -O0 decimal.cpp -o decimal decimal.cpp:1:19: fatal error: decimal: No such file or directory compilation terminated. When the include path is included explicitly compilation works fine: $ /opt/at5.0/bin/g++ -isystem /opt/at5.0/include/c++/4.6.2/decimal/ -m64 -O0 decimal.cpp -o decimal Here's the version information for the compiler: $ /opt/at5.0/bin/g++ -v 2>&1 | grep version gcc version 4.6.2 20110919 (Advance-Toolchain-5.0-1) [ibm/gcc-4_6-branch revision 181060] (GCC) I'm operating under the assumption that #include <decimal> should pick up the include/c++/4.6.2/decimal/decimal header automatically without having to specify -isystem on compiler invocation.
The entire testsuite uses <decimal/decimal>, can't be by chance. Let's add Janis in CC, maybe she can give you further clarifications.
I assume the reasoning is similar to how we require users to include <tr1/memory> to get TR1's <memory>
Thanks. Using #include <decimal/decimal> instead of #include <decimal> does indeed work. I'm just wondering what's correct.
With the difference vs tr1, that in this case, as far as I can see, there are no name collision issues, thus installing both decimal and decimal.h at the the same level of the the other standard headers would be trivial, if we wanted.
Header <decimal> didn't go with the standard headers because it's not part of the standard. My first couple of patches put it in <tr24733/decimal> on the recommendation of Benjamin Kosnik. Ed Smith-Rowland in <http://gcc.gnu.org/ml/libstdc++/2009-10/msg00012.html> suggested putting it in <decimal/decimal> instead, where it would be just as hidden from standard files but more recognizable. Benjamin agreed and made that change. I don't care where it goes, just wanted to clarify why it is where it is now.
Agreed. Thus, I understand the behavior is absolutely intended, and I see no compelling reason to change it now.
(In reply to comment #6) > Agreed. Thus, I understand the behavior is absolutely intended, and I see no > compelling reason to change it now. Would you see this changing to be located in the standard include directory should the ratification of the TR take place? (yeah I know, we're probably on the order of geologic time for that to happen)
personally, yes, I'd be happy with <decimal> when it's a standard