Re: Non-const overload of std::string::data()
On 5/31/07 12:30 PM, in article e%e7i.23624$%k.105776@twister2.libero.it,
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
(this is a follow-up of thread "std::string::data()" in
comp.lang.c++.moderated)
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[0] to portably obtain a non-const pointer to the string internal buf=
fer.
Not quite: according to N2284 &s[0] points to a character buffer that is
neither modifiable (see =A721.3.4) nor internal to the std::string object=
(see
Table 39). Furthermore, there is no requirement that a std::string even h=
as
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=
s
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=
hat
the non-const data() overload could be used to modify the string itself -=
a
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[0] 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=
e
direct public access to this internal representation - would be a colossa=
l
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
- 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=
t
that is just as transcendent: std::string.
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]