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: 23.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, 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 24.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 23.4.3 [basic.string], paragraph 2.
The characters in a string are stored contiguously, meaning that if s is a basic_string<charT, Allocator>, then it obeys the identity &*(s.begin() + n) == &*s.begin() + n for all 0 <= 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.