<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2084: basic_string use of charT*</title>
<meta property="og:title" content="Issue 2084: basic_string use of charT*">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2084.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#NAD">NAD</a> status.</em></p>
<h3 id="2084"><a href="lwg-closed.html#2084">2084</a>. <code>basic_string</code> use of <code>charT*</code></h3>
<p><b>Section:</b> 27.4.3 <a href="https://wg21.link/basic.string">[basic.string]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-09-11 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>

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

<blockquote><pre>
typedef typename allocator_traits&lt;Allocator&gt;::pointer       pointer:
typedef typename allocator_traits&lt;Allocator&gt;::const_pointer const_pointer;
</pre></blockquote>

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

<blockquote><pre>
basic_string(const charT* s, const Allocator&amp; a = Allocator());
</pre></blockquote>

<p>
Was this an oversight? Did we mean instead:
</p>

<blockquote><pre>
basic_string(const_pointer s, const Allocator&amp; a = Allocator());
</pre></blockquote>

<p><b>Rationale:</b></p><p>
It's intentional. <code>char_traits</code> assumes that all elements of
a string can be accessed indirect on plain pointers. So <code>basic_string</code> 
doesn't support allocators with fancy pointers or references. And we meant 
to do that.
<p/>
Let's take the constructor example you called out:
</p>

<blockquote><pre>
basic_string(const charT* s, const Allocator&amp; a = Allocator());
</pre></blockquote>

<p>
This constructor allows us to create a <code>basic_string</code> object from a string literal.  
If we were to change the pointer type, that would no longer be possible.
<p/>
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 <code>allocator::pointer</code> type.
<p/>
Now what about the return value of '<code>c_str()</code>', should that return an <code>allocator::pointer</code>?
<p/>
Again, the answer (I believe) is 'no' because this is the function that allows us 
to pass the string's contents to a legacy&#47;OS 'C' API. It is deliberately returning 
a raw pointer for a reason.
<p/>
There was an issue where <code>vector::data</code> was changed to return an <code>allocator::pointer</code>
to the internal buffer, and this was changed back exactly because this was intended 
to support passing to external APIs.
<p/>
Do we have a use-case where the pointer type of internal data structures of our 
containers (notably <code>basic_string</code> and <code>vector</code>) need to be exposed through a public API?  
All my current use-cases for <code>allocator::pointer</code> are specific to the implementation 
of containers themselves.
</p>



<p id="res-2084"><b>Proposed resolution:</b></p>





</body>
</html>
