Re: [boost] Interest in super string class?

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2006-07-05 10:08:58

On Tue, 04 Jul 2006 16:40:49 -0400
Edward Diener <eddielee_at_[hidden]> wrote:

> I pointed out what I thought was the only bad design decision in 
> std::string, but it's a done deal already and the mavens of C++ 
> evidently want to support C idioms for the life of the language so who
> 
> am I to object. Other than that, the much-maligned design of
> std::string  is actually excellent,

Sure, the C-centric viewpoint is a problem.  However, IMO, the biggest
problem with std::string (yes, others fall into the a similar
category)...  some very significant implementation details are left to
the implementor, with no choice for the user.  Yeah, I know... you are
not supposed to be concerned with what's behind the interface.  However,
in the real world, at some point you must be concerned with those
issues.

Many applications will perform terribly with unique copies underneath
every std::string.  Likewise, many applications will perform terribly
with ref-counted COW strings.  Many applications have a small
multithreaded need, but are yoked with mutex locking for each string
operation of some implementations.

Worse, move your code between compilers and you will get different
behavior.  I would love to see more string options, so that I can choose
when unique strings are best, or non-mutex protected COW operations are
acceptable.

Personally, I don't care if the strings have different names, or are
typed based on policies, or there is a special type that defers the
implementation to some type of strategy object.  Obviously some are
better than others, but either would be better than being saddled with a
class that can not be used in some situations because you have no idea
what it will cost to use.

We have a home grown string library that has its own problems.  However,
at the time, we were using two different versions of two different
compilers, and each was using a different string implementation.  Where
string behavior is required to be pre-determined, how are you supposed
to use std::string when its requirements allow such different behavior? 
The answer was (and I believe still is)... you can't.  It sure would be
nice to have all that std::string functionality (and interoperability)
available to me even if I need a different underlying implementation.