backward compatibility for V3 g++/libstdc++?

[Scott Johnston <scott at accom dot com>]

Greetings,

I am currently experimenting with compiling ivtools-0.9.3
(http://www.ivtools.org) with a copy of gcc-3.0 (built from a 5/31/01
cvs repository checkout with egcs-1.1.1 on RH6.2 Gnu/Linux).
I compliment you on the smoothness of the process of building and
installing the entire environment.  I was expecting the usual minor
changes to my source code, but was surprised to find a great deal of
work will be required to complete the port.  I have searched for an FAQ
that might address my concerns, but haven't found any.

Before I list the specifics, I would like to emphasize that I have no
problem with an ANSI compatible C++ compiler and programming environment
(and forgive my ignorance of what that standard is).  But I am more
interested in a g++/libstdc++ compatible environment, because that is
all I've been using for the past twelve years.  And if the problems I've
encountered are simply resolved with -fpermissive, let me know, and I'll
go happily on my way.   But I think most of them stem from changes to
libstdc++ that mandate changes to this existing C++ software.
Alternately, if these problems will be cleared up in the near future,
I would appreciate knowing that, and I will simply wait awhile before
trying gcc-3.* again.

First off, some very useful methods are missing, and a quick perusal of
the new include files did not reveal their equivalent, i.e.
filebuf::attach() and ostream::form().  In the past I have found
C++ iostream programming required a great deal of experimentation to
perfect, and I would rather not have to duplicate this effort if at all
possible.

Secondly, the iostream classes have been templated, which I assume is
part of the ANSI standard, and not a bad idea, but it requires replacing
forward declarations of istream and ostream with #include <iostream>.
 Could there be (or is there) a define switch which removes the
templated streams and restores the simple one-byte streams?  Can
templated and simple iostream classes live side-by-side?

Next, I've found that ubiquitous C functions from string.h are now part
of the std namespace.  One workaround is to include the C version of
string.h before any other C++ include files, but this introduces an
ordering dependency on include files, something I've been able to avoid
until now.  Namespaces are great, but would it be possible to have
K&R C functions available outside of them?

There are more issues, but feedback on these would be helpful for now.
I've also found that my workarounds (#include'ing <iostream> instead of
forward declarations, global using of std namespace) significantly slows
compile time on affected files.   My concern is for more than the free
software I publish.  I worry that an amazing amount of legacy
C++ software that has been compiled with g++ and linked against
libstdc++ for years will be lost to future programmers if these problems
cannot be minimized.

If those working on V3 of libstdc++ and gcc are interested, I would
offer ivtools as a backward-compatible test suite for the compiler, and
work with them to change things as necessary, where necessary.  GNU is
bigger than ANSI, which is something I've always appreciated.

Thanks for your efforts,

Scott Johnston
http://www.ivtools.org


p.s.  The gcc-3.0 release criteria says this about libstdc++:

C++ Standard Library

       The standard library is a part of the ABI. Changing the standard
library interfaces is effectively a change in the ABI. It is important
that we
       provide a standards-conforming C++ standard library.


I would propose that some degree of backward compatibility be added as
well.   Or at least the creation of a document that explains what
backward compatibities are impossible.