Re: Replacing a quote by a "\n" ...
On Nov 28, 4:01 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Nov 27, 6:25 pm, "Alf P. Steinbach" <al...@start.no> wrote:
[...]
Again, re optimization: std::string is not well suited for string
handling. It's not even well suited for passing strings around,
technically. But it's standard, and that's one great plus point, so
great that std::string is the default choice for that.
As a summary of std::string, this is actually pretty good. But
to be fair: std::string does define both the copy constructor
and an assignment operator---what else do you need for passing
strings around?
Efficiency, safety and possibly more information.
Most of these really concern creation of strings, rather than
just "passing them around". One point, however:
[...]
- being able to avoid copying for forming substrings
This is a deficiency in most current implementations, but is not
necessary according to the standard. An implementation more or
less like that of Java could be used, in which you don't need a
copy for substrings.
[...]
- e.g. character set.
Achieving this "normality" (what one naturally expect of a
string type, unless exposed to std::string for too long...)
needs a new string interface.
Having had to deal with "bad" string types in other languages
(in the past), I don't naturally expect very much:-). (Or is
that I naturally don't expect very much?)
The lack of information concerning the encoding (character set)
is an awkward problem. It is one, however, that we're used to
dealing with: it affects a lot of other types as well. (Is that
double meters, or millimeters? Is that Decimal Euros, or
Pounds?)
In the end, I think we need both: a "raw" type, for cases where
the "units" are implicitly known, and a more complete type which
associates a unit with each value. (Note that I'm not talking
here about typing issues, where the user assigns a double
representing meters to a variable containing the weight. That's
a different problem---which probably needs solving as well.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34