This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.

876. basic_string access operations should give stronger guarantees

Section: 27.4.3 [basic.string] Status: C++11 Submitter: Daniel Krügler Opened: 2008-08-22 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 C++11 status.

Discussion:

During the Sophia Antipolis meeting it was decided to split-off some parts of the n2647 ("Concurrency modifications for basic_string") proposal into a separate issue, because these weren't actually concurrency-related. The here proposed changes refer to the recent update document n2668 and attempt to take advantage of the stricter structural requirements.

Indeed there exists some leeway for more guarantees that would be very useful for programmers, especially if interaction with transactionary or exception-unaware C API code is important. This would also allow compilers to take advantage of more performance optimizations, because more functions can have throw() specifications. This proposal uses the form of "Throws: Nothing" clauses to reach the same effect, because there already exists a different issue in progress to clean-up the current existing "schizophrenia" of the standard in this regard.

Due to earlier support for copy-on-write, we find the following unnecessary limitations for C++0x:

  1. Missing no-throw guarantees: data() and c_str() simply return a pointer to their guts, which is a non-failure operation. This should be spelled out. It is also noteworthy to mention that the same guarantees should also be given by the size query functions, because the combination of pointer to content and the length is typically needed during interaction with low-level API.
  2. Missing complexity guarantees: data() and c_str() simply return a pointer to their guts, which is guaranteed O(1). This should be spelled out.
  3. Missing reading access to the terminating character: Only the const overload of operator[] allows reading access to the terminator char. For more intuitive usage of strings, reading access to this position should be extended to the non-const case. In contrast to C++03 this reading access should now be homogeneously an lvalue access.

The proposed resolution is split into a main part (A) and a secondary part (B) (earlier called "Adjunct Adjunct Proposal"). (B) extends (A) by also making access to index position size() of the at() overloads a no-throw operation. This was separated, because this part is theoretically observable in specifically designed test programs.

[ San Francisco: ]

We oppose part 1 of the issue but hope to address size() in issue 877(i).

We do not support part B. 4 of the issue because of the breaking API change.

We support part A. 2 of the issue.

On support part A. 3 of the issue:

Pete's broader comment: now that we know that basic_string will be a block of contiguous memory, we should just rewrite its specification with that in mind. The expression of the specification will be simpler and probably more correct as a result.

[ 2009-07 Frankfurt ]

Move proposed resolution A to Ready.

[ Howard: Commented out part B. ]

Proposed resolution:

    1. In 27.4.3.5 [string.capacity], just after p. 1 add a new paragraph:

      Throws: Nothing.

    2. In 27.4.3.6 [string.access] replace p. 1 by the following 4 paragraghs:

      Requires: pos ≤ size().

      Returns: If pos < size(), returns *(begin() + pos). Otherwise, returns a reference to a charT() that shall not be modified.

      Throws: Nothing.

      Complexity: Constant time.

    3. In 27.4.3.8.1 [string.accessors] replace the now common returns clause of c_str() and data() by the following three paragraphs:

      Returns: A pointer p such that p+i == &operator[](i) for each i in [0, size()].

      Throws: Nothing.

      Complexity: Constant time.