Re: New STL implementation from SGI

[Joe Buck <jbuck@synopsys.com>]

I wrote:

> > The real issue (whenever we decide to pick up the new STL) is the string
> > class: do we use the SGI one, the existing one, or the one Ulrich Drepper
> > is working on?

Ulrich replies:

> Actually Nathan is doing the work.  Anyhow, we will not completely
> abandom the version we have in the moment since on some platforms
> space consumption is more important than speed and here the current
> implementation we have is superior.

Yes, the SGI implementation is basically a slightly different
vector<charT> that is always null-terminated, meaning that there is no
reference counting and string copy is a deep copy operation, but
conversion to/from const char* is cheaper.  I would prefer something that
works more like what we have (reference counting).

However, I am discouraged by the fact that we still don't have anything
available for testing.  I'd like to encourage the developers (e.g. you and
Nathan) to make available even partially working code so that others can
assist with testing, suggestions for improvement, etc.

> To decide which version we use somebody will have to make measurements
> with a thread-safe version of either implementation.  My guess is that
> the SGI version is faster since we don't have to care for locking.

Actually I suspect that the SGI version will be slower as well as require
more memory in some applications: if copying strings from place to place
is common, but concatenation is less common, a deep copy may cost more
than a reference count adjustment.  But other operations are faster
(e.g. get the string length without any indirection, c_str() is free etc).
Because of the different implementation tradeoffs, just tell me which
implementation you want to win and I will write you an appropriate
benchmark. :-)