This is the mail archive of the
mailing list for the libstdc++ project.
Re: backward compatibility for V3 g++/libstdc++?
- To: scott at accom dot com (Scott Johnston)
- Subject: Re: backward compatibility for V3 g++/libstdc++?
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Wed, 6 Jun 2001 16:48:13 -0700 (PDT)
- Cc: libstdc++ at gcc dot gnu dot org, johnston at vectaport dot com
Some of Scott Johnston's remarks have been addressed elsewhere, but ...
> 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
Now that there is an ANSI and ISO C++ standard, this should soon no longer
> 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>.
Actually, there is a special header
that just forward-declares the iostream templates and compiles faster.
> 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?
Microsoft tried that (two different iostream implementations). It's a
huge mess ... bad things happen if you include both in the same source
> 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.
This string.h behavior is a bug. <cstring> is supposed to put the
functions into std::, and the order is not supposed to affect string.h.
Until this bug is fixed, you can use the workaround of including string.h
> 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.