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

[Phil Edwards]

On Wed, Jun 06, 2001 at 05:20:02PM -0700, Scott Johnston wrote:
> 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.

You may not be used to the standardized manipulators yet, in which case
I recommend a good recent text.  But sprintf is still supported, of course.


> 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 need to make this absolutely clear, both here and for the archives:
that filebuf extension is there because we need it ourselves, in order to
make other parts of the library work.  It's not the result of a "what's
the most requested filebuf extension" popular vote or anything; it has
changed when we needed to change it.  /However/, it's there, it's useful,
it's a public member function, so we may as well document it and preserve it.


> I would still rank conformance to the GNU standard higher than conformance to
> the ANSI or ISO standard for g++ and libstdc++.

The only "GNU standard" I'm aware of is the coding standard (indentation,
etc), which we've adhered to pretty faithfully.  There is no GNU standard
for what classes and functions should be included in libstdc++.


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

Uhhhh...  libstdc++-v3 was merged in to GCC last April, and became the
default C++ library last November.  The world has had 7 or 8 months' worth
of weekly 2.97/3.0-prerelease snapshots to test their packages and programs.
It's far far too late to ask that "this new variant" be withheld until
individual distros get their say.

GCC 3.0 will be released in /eight days/.  The primary criteria (which
you noted) have been posted for months now, and it includes Debian systems
as both primary and secondary evaluation platforms.  If Debian wanted the
GCC steering committee to wait for their approval for individual projects,
Debian should have spoken up before.


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.