This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 27.4.3 [basic.string] Status: CD1 Submitter: Matt Austern Opened: 2005-11-15 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [basic.string].
View all other issues in [basic.string].
View all issues with CD1 status.
Discussion:
Issue 69(i), which was incorporated into C++03, mandated
that the elements of a vector must be stored in contiguous memory.
Should the same also apply to basic_string
?
We almost require contiguity already. Clause 23.4.7 [multiset]
defines operator[]
as data()[pos]
. What's missing
is a similar guarantee if we access the string's elements via the
iterator interface.
Given the existence of data()
, and the definition of
operator[]
and at
in terms of data
,
I don't believe it's possible to write a useful and standard-
conforming basic_string
that isn't contiguous. I'm not
aware of any non-contiguous implementation. We should just require
it.
Proposed resolution:
Add the following text to the end of 27.4.3 [basic.string], paragraph 2.
The characters in a string are stored contiguously, meaning that if
s
is abasic_string<charT, Allocator>
, then it obeys the identity&*(s.begin() + n) == &*s.begin() + n
for all0 <= n < s.size()
.
Rationale:
Not standardizing this existing practice does not give implementors more freedom. We thought it might a decade ago. But the vendors have spoken both with their implementations, and with their voice at the LWG meetings. The implementations are going to be contiguous no matter what the standard says. So the standard might as well give string clients more design choices.