Re: C++ library for egcs

[Joe Buck <jbuck@synopsys.com>]

> Some of you might already have heard that Nathan Myers and I currently
> rewrite the libstdc++ to be compliant with the FDIS...

> - we will follow as close as possible the standard.  This has some
>   consequences for code which does not use the library correctly.
>   Especially since martin is making great progress with the namespace
>   code some code which compiled in the past will have to be changed.

While I want us to have a standard-conformant library, I'm also worried
about breaking every C++ program in the world.  Will you provide
<iostream.h> that includes <iostream> and moves the iostream names
into the global namespace?  In compatibility headers we shouldn't say

using namespace std;

rather we should say

using std::ios;
using std::streambuf;
using std::istream;
using std::ostream;
using std::iostream;

etc (choose specifically which names to "pollute" the global namespace
with).  Only the "classic" names would need to be exported (those names
that were present before iostream became a template).

>   + code which uses internal headers not defined in the standard will
>     have to be changed.  The headers will be removed or at least renamed
>     or moved.

Which headers are you talking about?  stl_map.h and such?

> - headers will be cleaner.  I don't think this is a point to disagree :-)
>   It means that we will have no tons of #ifdef for all the different
>   architectures.  All remaining #ifdefs will handle fundamental options
>   like using exceptions or not, using namespaces or not etc.  Everything
>   will be controlled using feature select macros.  Those of you familiar
>   with the GNU libc can imagine who this works.

Great.  Will there be any issues with linking when a user chooses
different options (namespaces vs no namespaces).

> In discussions with the group working on the library at SGI (Matt,
> you're listening?) we've discussed the possibility to continue
> developing the together and even get to a single source distribution.

This would be a good thing.

> To make a close collaboration with SGI possible we will have to think
> about the license used for our libstdc++ code but work is underway and
> some of you were already contacted.  I cannot give more details on
> this now.

After the recent X11R6.4 experience some may be reluctant to loosen up
the license too much.  But the current license (GPL with an exception
if you use gcc) is clearly a problem for SGI, since they have their own
compiler; the license discriminates against other compilers (even free
ones like lcc).

One possibility is to just make a small change in the "special exception"
clause.  It now reads

// As a special exception, if you link this library with files
// compiled with a GNU compiler to produce an executable, this does not cause
// the resulting executable to be covered by the GNU General Public License.
// This exception does not however invalidate any other reasons why
// the executable file might be covered by the GNU General Public License.

s/files compiled with a GNU compiler/other files/

It would seem the effect is then like the LGPL but without the LGPL
rules on reverse engineering, or shipping in relinkable form.

> One of the demands of the SGI group was to add compatibility code.  We
> will most probably end up in adding such code (or mainly, add
> appropriate headers) but I am strongly against making this the default
> or even encourage people to use this option.  IMO broken code should
> be fixed _now_ and once.

I'm in favor of compatibility code -- not to provide bug-for-bug
compatibility but for people who carefully read the ARM when they
wrote their code, but are now hosed by namespaces and templated
stream classes.  The compiler is for the users, it is not just some
academic exercise where we get an A if we perfectly match the spec.

If compatibility code is present when users say <header.h> and absent
when they say <header> that seems like a reasonable approach, if it
can be made to work.  Older programs will generally use <header.h>.
But we shouldn't break the tradition that by default, we are somewhat
liberal, and users add switches like -ansi and -pedantic if they want
to be more rigorous.

The practice I'm most concerned about is that users tend to write

class ostream;

Historically this has been a wise thing to do -- compilation time on
big projects is improved greatly if you do this, and the committee
broke it.

> OK, that's what I can say in the moment.  Comments on this are
> appreciated.  If there are no complains we will start distributing the
> rewrite with egcs ASAP and replace the existing library completely as
> soon as we achieve a certain level of correctness.

I would like for the new code to be distributed.