On Tue, 04 Jul 2006 16:40:49 -0400 Edward Diener <eddielee@tropicsoft.com> 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.