From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: pnagel@epiuse.co.za Cc: egcs@cygnus.com Subject: Re: New STL implementation from SGI Date: Fri, 10 Jul 1998 13:32:00 -0000 Message-id: <199807101656.JAA11370@atrus.synopsys.com> References: X-SW-Source: 1998-07/msg00389.html > 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.