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

[Phil Edwards]

Thanks for your thoughtful note.  This was one of the /calmest/ emails
I've read lately.  :-)

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

Those were GNU extensions (originally from libg++, maybe?) that don't exist
in the ISO standard.  For form() you should be able to use stringstreams[1]
with minimal effort.  attach() is a different animal; it assumes the files
are handled via a specific non-portable technique (file descriptors).
If you feel like playing fast and loose, one of the "not really meant for
public use" extensions[2] to the I/O library will help you.

For 3.0, our goal was standards compliance.  For 3.1, we may have more
use-visible features and extensions available.  (Gotta maintain our leading
edge position. :-)


[1] see http://gcc.gnu.org/onlinedocs/libstdc++/21_strings/howto.html
[2] see http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html

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

Some notes:

For simple forward declarations of I/O classes, simply include <iosfwd>.
Forward decls of things involving templates and default template parameters
involve a syntax best described as "powerful ugly," so the ISO folks made
<iosfwd> for just this reason.

If you need actual definitions of the istream and ostream classes, they
have <istream> and <ostream> standard headers.

The only thing you get from <iostream> that you don't get from
<istream>/<ostream> are the declarations of the global objects cin, cout,
and so forth.  If you don't need cin, cout, et al, but only need the class
definitions and <</>> overloads, then use <istream>/<ostream> instead.
There's a good chance you'll save some cycles during program loading and
initialization.

There are backward-compatibility headers like <iomanip.h>, but the
differences are in namespaces, not the presence or lack of templates.
The non-templated versions are dead and gone (and good riddance), but with
the help of <iosfwd> and some standard typedefs[3], you shouldn't see that
much of a difference.

My one experience with using templated iostreams and "old" iostreams in
the same program still leaves me with screaming nightmares.  Maybe that
was just the compiler I was using at the time (MSVC6).  Not saying it
can't work, but I wouldn't advise it.


[3] e.g., ofstream is a typedef for basic_ofstream<char>, thus doing the
template work for you already.


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

<string.h> is still legal and valid.  More generally, the standard C
library is part of the standard C++ library.

At this very moment, there are some tricky issues with those functions
(lots of "ambiguous function call" messages, but those will be fixed for 3.0.


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

Known problem.  A bunch of compiler speedups are waiting for 3.0 to get
out of the way before we start bringing them in (which will cause some
destabilization), e.g., 'export' and precompiled headers.


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

We also ship a bunch of 'backward' headers for things which never officially
existed (as far as ANSI/ISO/etc go), but have just become commonly used
anyhow, like <vector.h> and <iostream.h>.


Luck++;
Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.