From mboxrd@z Thu Jan  1 00:00:00 1970
From: Josh Stern <jstern@citilink.com>
To: jbuck@synopsys.com, pnagel@epiuse.co.za
Cc: egcs@cygnus.com
Subject: Re: New STL implementation from SGI
Date: Sat, 11 Jul 1998 06:31:00 -0000
Message-id: <199807111329.IAA26107@homebase.citilink.com>
X-SW-Source: 1998-07/msg00413.html

>> 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, 

The idea of user control is good.

>you could do different definitions in different compilation 
>units as long as you don't pass strings between units.  

If I was working on a multi-user project, I'd be scared of the
confusion resulting from such a restriction (I'd like to name
the classes different things that could turn out to be typedef'd
to the same implementation).  But the idea
of using different versions to address implementation tradeoffs comes
up over and over.  For instance, with the STL map/set/multimap etc.
classes there is a tradeoff between, on the one hand, best
small project speed and readability with a pure template solution,
and on the other hand, best space efficiency with a solution that
maps different template classes to common code based on
manipulation of void* pointers (I don't know whether
that runs into problems with exceptions, but the idea is clear).

One idea to consider is distributing a directory of c++contrib code
that #ifdef'd typedefs in user code could access based on the 
macro-defined compiler name and version number.  That should
make it easy to work around portability issues.


- Josh