Re: New STL implementation from SGI

[Joe Buck <jbuck at synopsys dot com>]

> > I think upgrading the STL code would be wise for egcs-1.2.  
> > 
> 
> What is the time table for 1.2?

Possibly we should attempt a smaller cycle for 1.2.  But I'd like for
1.2 to be the release which finally has the new libstdc++.

> FYI, I know some C++ codes use auto_ptr.
> I have to fix it in egcs 1.0.3.

And I know some codes that use namespaces.  I would like to get the
new STL out too, but you have to decide if 1.1 is to be a stable
release or not.

Now, for classes that previously did not exist (like auto_ptr) it would
be risk-free to add them from the new STL -- it cannot break any old
code.  If you only want auto_ptr, then we could do that.

> It may be a good idea
> to include a better STL in egcs 1.1, since more and more C++ codes
> are using STL, even if it means 1.1.1.

We can't introduce new features into 1.1.1.  If we do something major
like a new STL, it is 1.2.  Note that this doesn't say anything about
timing; 1.2 could come one month after 1.1 if it is ready.

> Delaying it means people
> may say "don't use STL in egcs and get a real one in stead".

I think that the new STL should go into the snapshots ASAP.  But it
can't go directly into the release -- that would be irresponsible
(inadequate testing).

> As far
> as they know, STL in egcs is broken since 1.0 and it is broken.

What do you mean?  The existing STL works quite well.  True, there
have been improvements.

We will have to mention that the egcs 1.1 release is an old SGI release,
which is kind of embarrassing.  If you want the new SGI release into
egcs 1.1, this is possible -- *if* we move all the dates back (feature
freeze will have been extended).

Unfortunately there are some issues: the new SGI STL has a standard
string class.  But we already have a string class.  And Uli has a new
(yet a third) standard string class.  Which one should we use?

Maybe it's best to release what we have, and *then* settle issues like
this.