[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

["bkoz at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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