------- Comment #70 from marc dot glisse at normalesup dot org 2010-04-29 10:27 ------- (In reply to comment #68) > (In reply to comment #63) > > > > Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the > > namespace std versions of functions, and not also the global scoped ones. > > This > > is a problem. The way I read ISO C++, cstdlib should only have std:: scoped > > bits. The C++ compatibility include stdlib.h should then re-scope to :: > > (global). Solaris tries to smash these two concepts together. Boo. > > This is no longer a problem: > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456
It was not so hard to work around in any case (see rest of the discussion). > Can we consider defining __cplusplus to the correct value in C++0x mode, even > if we leave it at 1 for 98/03 mode? The reason for not defining it to the correct value is not that it would yield an unclean situation (which is already the case). There are several issues: - breaks the ABI because tm and a couple other structs move from the global namespace to namespace std. This can be worked around by forcing the mangling of std::tm to be that of ::tm, but it is ugly. - needs to remove the overloads on linkage (like bsearch, qsort) in the solaris headers because g++ is broken there. - needs to adapt redefine_extname to remove its limitation to the global namespace. - needs to conditionally remove the overloads from libstdc++ that are already in the solaris headers (like the math functions) and deal with the fact that afterwards, including math.h instead of cmath will mean that cos(int) fails, at least until Oracle writes C++0X headers (might take a few years). Or fixinclude out almost anything that __cplusplus enables... I had a proof of concept in some PR some time ago, but the fixinclude part was a bit heavy... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
