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