Re: std::string bad design????
Earl Purple wrote:
Ivan Vecerina wrote:
[...]
- Lack of a "const string", whose contents cannot be modified.
std::string was initially thought to use reference-counting
and copy-on-write. However, this prove to be excessively
difficult to implement efficiently, especially in a multi-
threaded environment. As a result, several std::string
implementations have given up on using reference-counting.
Lack of a standard layout in my opinion is a major flaw.
A standard layout is impossible, since regardless of the
implementation, much will depend on implementation dependant
types (e.g. size_t). As a general rule, you cannot link code
compiled with two different C++ compilers.
Some platforms do provide a C++ API specification. Presumably,
that specification would include things like the layout of
std::string. (Otherwise, it is incomplete, and for all intents
and purposes, useless.)
That means that I can't write library function to return a
std::string if the other end is not using the same
implementation of STL that I am using.
Which is normal, since both the caller and the callee must be
compiled with the same compiler.
[...]
- Excessive number of member functions: std::string has
more members than any other standard library class. Yet it
is far from being complete or satisfactory (e.g. novices
commonly look for trim, split, toupper, etc functions found
in other libraries or languages). The STL has set a nice
precedent by separating algorithms from containers. The
same could have been done with std::string: provide
non-member functions to perform any non-fundamental
string manipulations. This would have set a precedent
allowing uniform extensibility of std::string: for example
we could add a header that provides all internationalization-
related functions, etc. And for basic uses std::string
would remain leader. Now we have a bulky class, and
a dichotomy between a set of member functions and the rest
of the world. This in turn leads many novices to think that
they need to subclass std::string to add operations that
they miss.
They miss two things, a converter to upper/lower (can be done with
std::transform) and a comparison function that is case insensitive
(could be done with an external predicate). You would expect to find
these perhaps in std::locale but they're not there.
They definitly belong in std::locale, and not in std::string.
(And of course, there's no way that std::transform can be used,
since you cannot transform byte by byte, without context, and in
certain cases, even the number of letters will be different.)
I would like a swap between std::basic_string<E> and std::vector<E>.
Impossible, given that they aren't required to use the same
implementation (and typically don't). If they were, then what's
the point of having std::basic_string to begin with: just define
global functions for the character handling, and make
std::string a typedef to std::vector<char>. (That's actually
not a bad idea. For most of the things I do, at least,
std::vector<char> is a better string class than std::string.)
I would like a proper efficient char_traits for any primitive
integral type.
In order to be useful, you'd also have to assume similar
instantiations for most of the facets in locale, for the
iostreams, etc.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]