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

[Scott Johnston <scott at accom dot com>]

Thank you Phil and Joe for your responses.  The <iosfwd> tip is helpful.

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

The ostream::form I'm interested in accepts a printf-like format string.
stringstreams prints to a string alright, but you don't have fine-grained
control over the format in a way that I'm used to.  This one is not a problem,
I will revert to using sprintf, with care taken in buffer size allocation.

It looks like I'm hoping for rapid expansion to the "extensions" page.  The
filebuf extension looks good, but it uses FILE* instead of a file descriptor,
and the interaction between the two kinds can be tricky (has been tricky in the
past in the context of sockets programming).

I would still rank conformance to the GNU standard higher than conformance to
the ANSI or ISO standard for g++ and libstdc++.  Has libstdc++-v3 been vetted by
the Debian project?  I would be curious to see the list of required
"extensions" that come up when every C++ package they manage is ported to
gcc-3.0.  It would seem wise for the gcc steering committee to forgo approving
this new variant of the compiler until we are well through that process.  I know
that libstdc++-v3 became the approved variant of libstdc++ with gcc-2.95.3 (I
can tell by the pain my users are feeling), but it is an easier thing to tell
them to fall back to an older,still separate copy of libstdc++ than to tell them
to avoid using an approved new release of gcc with bundled libstdc++.

Once again, thanks for your feedback.

Scott Johnston
http://www.ivtools.org