------- Comment #6 from bkoz at gcc dot gnu dot org 2007-12-11 22:56 -------
The gcc-4.3 release intentionally changes the libstdc++ API. It is intended with this release that either: C++98 or C++0x will be used, and that either dialect will work with both TR1 and the various extensions listed here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#2.0 I'm interested in making this change with the least amount of trauma possible. Some cannot be avoided. The hope is that the new interfaces will be acceptable, and that the resulting library organization is coherent for the lifespan of C++0x and future library hacking. You ask: how can 4.2 and 4.3 libstdc++ APIs be differentiated? Of course, the usual hackery of GCC predefined macros applies in this situation: __GNUG__ >= 4 && __GNUC_MINOR__ >= 3 would work. However, I think a functional test is a much better way to go. You'll find a list of autoconf macros to help you through this transition here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/backwards_compatibility.html In particular: AC_HEADER_PRE_STDCXX AC_HEADER_STDCXX_98 AC_HEADER_STDCXX_TR1 AC_HEADER_STDCXX_0X Should be sufficient to wrap client code. If these (or the other macros on this page) is insufficient, please let me know. To address your comment in #3, I will refer you to: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/api.html >From this, you'll see that the majority of the backwards headers recently removed were first added for gcc-3.0.0. They have always been marked deprecated, subject to future removal. Thus, to take a longer-term view of compiler portability, their presence could never be counted on, even without the recent removal. To be completely honest, I think adding these headers in 3.0.o0 (when they were not part of gcc-2.72, gcc-2.95, egcs, etc) was a mistake. In any case, these headers have been problematic in recent times. Some don't compile (defalloc.h, perhaps others), some get in the way of other functionality (complex.h), many are completely unused, and all contribute to mental anguish on the part of maintainers struggling to keep various C++ dialects, TR1, extensions, and extension modes (debug/parallel) straight and compiling within the constraints of multiple (approved) mixings. Hope this clarifies the situation. best, benjamin best, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
