This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 27.4.3[basic.string]Status:CD1Submitter: Matt AusternOpened: 2005-11-15Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [basic.string].
View all otherissues in [basic.string].
View all issues withCD1 status.
Discussion:
Issue69(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 tobasic_string?
We almost require contiguity already. Clause 23.4.7[multiset] definesoperator[] asdata()[pos]. What's missing is a similar guarantee if we access the string's elements via the iterator interface.
Given the existence ofdata(), and the definition ofoperator[] andat in terms ofdata, I don't believe it's possible to write a useful and standard- conformingbasic_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
sis abasic_string<charT, Allocator>, then it obeys the identity&*(s.begin() + n) == &*s.begin() + nfor all0 <= n < s.size().
Rationale:
Not standardizing this existing practice does not give implementors morefreedom. We thought it might a decade ago. But the vendors have spokenboth with their implementations, and with their voice at the LWGmeetings. The implementations are going to be contiguous no matter whatthe standard says. So the standard might as well give string clientsmore design choices.