Re: Non-const overload of std::string::data()
On 5/31/07 12:30 PM, in article email@example.com,
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
(this is a follow-up of thread "std::string::data()" in
The latest draft (N2284) includes wording from issue #530, which adds a
requirement to std::basic_string: the string elements must be stored
contiguously in memory. It has been noticed in the cited thread that
such a requirement effectively makes it possible to use the expression
&s to portably obtain a non-const pointer to the string internal buf=
Not quite: according to N2284 &s points to a character buffer that is
neither modifiable (see =A721.3.4) nor internal to the std::string object=
Table 39). Furthermore, there is no requirement that a std::string even h=
to maintain an internal character buffer as such in the first place.
basic_string has a const data() member, but not a non-const overload.
However, obtaining a non-const pointer to the internal buffer is perhap=
the #1 FAQ about basic_string. Whatever rationale there was for not
providing the non-const overload has now been superseded by #530, IMHO.
I say we should just provide it.
What for? A non-const data() overload would create the false impression t=
the non-const data() overload could be used to modify the string itself -=
sheer impossibility in light of a std::string's design guarantees.
Specifically: in order to support std::string implementations that use
reference-counting - every modification to a std::string object must be
mediated by its class interface. So, at the very least, a non-const
std::string data() method would break every existing reference-counted
std::string implementation, by bypassing std::string's interface.
Notice that issue #464 (which has also been included in the latest
draft) adds to std::vector both const and non-const overloads of the
member data(). One of the reasons for this addition is precisely to
avoid the use of the &v idiom. This makes the lack of a non-const
data() in basic_string even more embarrassing.
On the contrary, imposing a specific internal data structure on a
std::string implementation - and then requiring that the interface provid=
direct public access to this internal representation - would be a colossa=
design embarrassment for C++ - and one that the language could probably
never be able to live down completely. By tossing the principles of data
encapsulation, public interfaces and object-oriented design out of the
window, a std::string object would be little more than - and no better th=
- an ordinary C struct after all.
A C++ program should use the class that best fits their needs. So if a
program needs a sequence of characters, it should use a std::vector<char>=
likewise for a stream or buffer of characters, a program should use a
std::stringstream. But if a program needs a string class that transcends
those two narrow concepts of a "string", then it should use a class objec=
that is just as transcendent: std::string.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:firstname.lastname@example.org ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]