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

2084. basic_string use of charT*

Section: 27.4.3 [basic.string] Status: NAD Submitter: Howard Hinnant Opened: 2011-09-11 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 NAD status.

Discussion:

For C++11 we gave all of the containers, including basic_string new generalized pointer types:

typedef typename allocator_traits<Allocator>::pointer       pointer:
typedef typename allocator_traits<Allocator>::const_pointer const_pointer;

However, the constructors, assignment, and member functions still traffic exclusively in terms of const charT*, for example:

basic_string(const charT* s, const Allocator& a = Allocator());

Was this an oversight? Did we mean instead:

basic_string(const_pointer s, const Allocator& a = Allocator());

Rationale:

It's intentional. char_traits assumes that all elements of a string can be accessed indirect on plain pointers. So basic_string doesn't support allocators with fancy pointers or references. And we meant to do that.

Let's take the constructor example you called out:

basic_string(const charT* s, const Allocator& a = Allocator());

This constructor allows us to create a basic_string object from a string literal. If we were to change the pointer type, that would no longer be possible.

There is no issue here, as the implementation of the constructor must make a copy of the string pointed-to by the pointer 's' rather than adopt ownership of that buffer. It is that internal copy that must make use of the allocator::pointer type.

Now what about the return value of 'c_str()', should that return an allocator::pointer?

Again, the answer (I believe) is 'no' because this is the function that allows us to pass the string's contents to a legacy/OS 'C' API. It is deliberately returning a raw pointer for a reason.

There was an issue where vector::data was changed to return an allocator::pointer to the internal buffer, and this was changed back exactly because this was intended to support passing to external APIs.

Do we have a use-case where the pointer type of internal data structures of our containers (notably basic_string and vector) need to be exposed through a public API? All my current use-cases for allocator::pointer are specific to the implementation of containers themselves.

Proposed resolution: