Re: std::basic_string<> contiguous data?
Howard Hinnant wrote:
In article <127tr2pjlnhia6mgidlmdr5aqnupp94oso@4ax.com>,
Gennaro Prota <clcppm-poster@this.is.invalid> wrote:
On Tue, 23 Jan 2007 10:40:42 CST, James Kanze wrote:
[about contiguous basic_strings]
The SGI rope class is very close to std::string, and uses
non-contiguous memory. Unlike the case with vector, this
possibility was actually discussed at the time; it was an
intentional decision not to require contiguous memory, because
requiring contiguous memory imposed certain trade-offs that the
committee didn't want to impose.
It is a great fortune that you recall this (if only someone had
volunteered to write a C++ rationale...) Perhaps you have access to
the committee reflectors to point this out? I'm sure that would be
carefully considered. Alternatively I think you can send a note to
Howard Hinnant.
Fwiw the LWG is aware of the existence of rope, and the history and
rationale for std::string. Though no doubt we welcome input from both
Gennaro and James.
Well, I really don't have any strong opinion vis-a-vis the
contiguous memory requirement. My own feelings concerning
std::string are:
-- I don't like the interface---I definitly would have done it
differently---, but
-- it's quite usable anyway, and
-- special requirements will require a special, user defined
class, but that would be true for any general purpose string
class.
I know that the committee was aware of rope when the standard
was first adopted. That's what I meant when I said that the
decision not to require contiguity was intentional (unlike the
case with std::vector).
A decade ago we didn't have the experience that we do now with
std::string. After a decade, no vendor has shipped a non-contiguous
string. Vendors have in that time period, done complete rewrites of
string (I've personally rewritten it 3 or 4 times). The spec all but
requires contiguous memory. No vendor has shipped, or has any plans to
ship, a non-contiguous string. Given this existing practice, it makes
sense to just standardize existing practice so that clients can take
advantage of the de-facto standard with more confidence in the future of
their code.
Certainly. What good would experience be if we didn't learn
from it? As I say, this one doesn't seem that important to me,
but that's not a valid argument against it.
--
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! ]