Re: New STL implementation from SGI

[Joe Buck <jbuck at synopsys dot com>]

> Ouch! I've been happily using strings to pass around megabyte-sized
> blobs of data, but reading about the SGI string class makes me want
> to run and reread the spec to check on how portable my use is - I
> thought C++ strings were *supposed* to have reference countng
> semantics.

This shows why Stepanov's (inventor of STL) notion of specifying
performance guarantees for library algorithms in standards is so
important.  Unfortunately this was only done for the STL part; there are
no performance guarantees on string operations, I'm afraid.
(Had the committee required that string assignment is constant time
and not dependent on length, this would have forced a reference-counting
or similar implementation).

> I'm all for including different implementations of the string class.
> How about renaming basic_string to shallow_copy_basic_string and
> deep_copy_basic_string respectively, and then have a mechanism to
> choose which one is typedefed to basic_string - thereby allowing one
> to write code that uses *both*?

Ah, but there is a *third* implementation possibility: you could base
your string class on the SGI "rope" class, which gives you yet another
performance tradeoff.  I supposed you could call the rope implementation
"lots_of_pieces_string".

Since the standard says there is just basic_string, any chosen mechanism
would have to compile standard programs and not pollute the namespace.
If you just do a #define, it is easy -- but the user has to use the same
#define for everything in the program.  If there is a controllable
typedef, you could do different definitions in different compilation units
as long as you don't pass strings between units.

Of course, constructors could be added to convert one form of string into
another -- however, we would have to be careful not to introduce
ambiguities by doing this.

But: some of us have to write code that runs through multiple compilers,
so we can only assume that there is one string class, with unknown
implementation.