Re: linux libio solution

[Joe Buck <jbuck at synopsys dot com>]

>  Robert> What's so important that stdio/iostream can be mixed?
> 
> I can think of several reasons.
> 
> 1. It is documented as working.
> 2. It is used by many existing programs.

But no conforming (to the draft standard) programs will break.

> 3. It is absolutely essential if you want to have mixed c/c++ code.

If you wish to write a portable program, it is possible to mix
stdin/out/err and cin/out/err but only if you use the sync_with_stdio
call.  In many implementations this causes a speed penalty (basically,
the iostreams operations flush all the time to make sure that the
output will mix right.  The Linux implementation has the advantage
that no speed penalty applies: cout and stdout are really the same
object.

>  Robert> This "feature" does not work on any other platform and has
>  Robert> caused so much harm.
> 
> Huh? It absolutely DOES work on other platforms.  And what harm does
> it cause?

The harm has been caused because of certain annoying details, not because
of the basic idea.  It really does make sense.  The problem has been
that libc has used a version of the libstdc++ stdio, but there have
generally been some differences; there also have been some changes in
the interface.  The result is that the FSF libg++ has never quite
worked with Linux and has always needed patches.

>  Robert> IMHO we should sacrifice it and provide to distinct
>  Robert> implementations for libc and libstdc++.
> 
> NO.

In an ideal world where libio has a fixed, immutable API, there would
be no reason to do this.  The problem is that there have been changes
in the interface (to support long double I/O, plus some other
re-architecting).

One possibility would be to have two modes of operation:

* one in which libio is shared, like now, and libstdc++ does not include
  libio but calls the Linux libio routines.  This would be suitable for
  "production" but would require recent libraries.  In the future, the
  interfaces between libstdc++ and libio would be kept fixed so that
  future libstdc++'s just "drop in".

* one where libstdc++ has its own internal libio, as it does on other
  OSes (e.g. Solaris).  Possibly some prefix would be added to the
  symbols so that they will not clash with the libio that is in libc.
  This mode would allow use of egcs on older Linux boxes (or pretty
  much any Linux box).  There would be a penalty in memory consumption
  for this, but it would only be paid once for the whole system (if
  shared libraries are used).

With the second scheme, there are separate buffers for cout and stdout.
Programs can use both if they do their own flushing and/or use
sync_with_stdio.