New STL & egcs

New STL & egcs

[Jeffrey A Law]

BTW, I should have mentioned  that I'm considering running egcs-1.2
off the same branch as egcs-1.1.

ie, we go through the egcs-1.1 release cycle, possibly making a few
minor releases as we deem it necessary.

Then we add the new STL code (and only the new STL code) to the release
branch and start the egcs-1.2 cycle.  That way we don't have to go through
the process of stabilizing the entire tree again -- which should allow
us to get egcs-1.2 out relatively quickly.  ie, egcs-1.2 works like
a minor release, except that it's got the new STL code.

I haven't discussed this with the steering committee, but it is one
way we can avoid adding the STL code to egcs-1.1 and still get a
release out with that code in a relatively short timeframe.

jeff

Re: New STL & egcs

[Joe Buck]

Jeff writes:

> BTW, I should have mentioned  that I'm considering running egcs-1.2
> off the same branch as egcs-1.1.
> 
> ie, we go through the egcs-1.1 release cycle, possibly making a few
> minor releases as we deem it necessary.
> 
> Then we add the new STL code (and only the new STL code) to the release
> branch and start the egcs-1.2 cycle.

The SGI STL v3.1 has code that conflicts with existing libstdc++ code
in at least two places: the string class, and the exception classes.
Both SGI and the existing libstdc++ provide versions.  The SGI string
class is superior in that it conforms to the standard and our existing
class does not.

To properly make these decisions we need to know more about the status
of the replacement libstdc++.  Can Ulrich Drepper or Jason Merrill comment
about the status?  When will a version be available for testing?  If you
want to keep it private, should we use the SGI string class or not?

(I'm for dropping the existing string and using the SGI one).

Re: New STL & egcs

[Ben Scherrey]

My present primary concern/desire is an ANSI C++ compliant compiler. If
the SGI string interface is the most compliant then I vote we go for it.
Any non-ANSI options should be supported optionally at best. The quicker
we get a compliant compiler/development system the quicker we get a
stable system that will break a lot less code. Anyone putting in the
effort to track egcs's progress is probably pretty up to speed on the
standard and prepared to deal with it. Right??? ;-)

Joe Buck wrote:
> The SGI STL v3.1 has code that conflicts with existing libstdc++ code
> in at least two places: the string class, and the exception classes.
> Both SGI and the existing libstdc++ provide versions.  The SGI string
> class is superior in that it conforms to the standard and our existing
> class does not.
> 
> To properly make these decisions we need to know more about the status
> of the replacement libstdc++.  Can Ulrich Drepper or Jason Merrill comment
> about the status?  When will a version be available for testing?  If you
> want to keep it private, should we use the SGI string class or not?
> 
> (I'm for dropping the existing string and using the SGI one).

Re: New STL & egcs

[Nathan Myers]

Joe Buck wrote:

> The SGI STL v3.1 has code that conflicts with existing libstdc++ code
> in at least two places: the string class, and the exception classes.
> Both SGI and the existing libstdc++ provide versions.  

I don't know of any reason to prefer the existing exception classes
over the ones in SGI-STL. 

> The SGI string
> class is superior in that it conforms to the standard and our existing
> class does not.
>
> To properly make these decisions we need to know more about the status
> of the replacement libstdc++.  Can Ulrich Drepper or Jason Merrill comment
> about the status?  When will a version be available for testing?  If you
> want to keep it private, should we use the SGI string class or not?
> 
> (I'm for dropping the existing string and using the SGI one).

There are valid reasons to support both strings.  The existing one 
(and the rewritten version of it) should be a lot faster and smaller in 
non-threaded applications.  The rewritten version should also be faster 
in threaded contexts where an atomic decrement-and-test is available, 
or where memory is dear and memory allocation is slow. 

The SGI version does not rely on reference-counting, and instead copies
the string contents promiscuously.  It might be faster in a threaded 
context in which reference-counting is expensive but both memory and 
memory allocation are (very) cheap.

It will be sensible to offer a config-time option.  However, for 1.2 
I would simply leave string (and perhaps exception) as-is, and simply
update the remaining components.

Nathan Myers
ncm@cantrip.org

Re: New STL & egcs

[Anthony Shipman]

> It will be sensible to offer a config-time option.  However, for 1.2 
> I would simply leave string (and perhaps exception) as-is, and simply
> update the remaining components.
> 
> Nathan Myers
> ncm@cantrip.org
> 

I might want to use the STL string in one application and the other in
another application.  I think that the config-time option should select
one as the default implementation of string and leave the other as an
alternative under another name.

-- 
Anthony Shipman                 "You've got to be taught before it's too late,
TUSC Computer Systems Pty Ltd    Before you are six or seven or eight,
666 Doncaster Rd, Doncaster      To hate all the people your relatives hate,
Melbourne, Australia, 3108       You've got to be carefully taught."  R&H