Re: String Iterators
On Apr 23, 2:20 pm, Richard Herring <junk@[127.0.0.1]> wrote:
In message <1176973016.729495.325...@e65g2000hsc.googlegroups.com>,
James Kanze <james.ka...@gmail.com> writes
[...]
-- There is currently no requirement that the data in a string
be contiguous; an implementation along the lines of SGI's
rope class is legal, for example.
The standard seems to be inconsistent here. 21.3.4 currently says that
operator[](pos) returns data()(pos), with no sign of an as-if
qualification.
There are a number of defects in the orginal text for string.
To be more accurate, it was the intent of the original standard
to allow an implementation along the lines of rope. As you say,
some of the text seems to contradict this intent (and other text
contradicts the contradictions).
In fact, no real implementation does this, and the C++
standards committee has decided (for the moment, at least)
to make contiguity a requirement in the next version of the
standard, just as it is for vector. There will also be a
non-const data() to return a pointer to the buffer, so you
don't have to jump through hoops to get it.
Since the non-const operator[](pos) supposedly returns a reference to
data()(pos), that's just as well ;-/
Yes:-).
In fact: the committee discussed the issues rather thoroughly.
Unlike the requirement for vector to be contiguous, this was not
considered a clarification, but a new restriction on
implementations. It was adopted on the basis of two arguments:
-- it's useful, for the same reason the requirement in vector
is useful, when interfacing to C API's, and
-- no implementation ever actually took advantage of the
liberty to be non-contiguous, so presumably, it wasn't an
important liberty.
On the whole, I think it's a good decision. In an ideal world,
you'd just use std::string for everything, it wouldn't matter,
and the best choice would be to leave a maximum of freedom to
the implementors. In the real world, however, it's a rare C++
program that doesn't have to interface with at least one API
specified in C, and simplifying that is easily worth the removal
of a little bit of implementation freedom, that no one used
anyway.
--
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