<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 421: is basic_streambuf copy-constructible?</title>
<meta property="og:title" content="Issue 421: is basic_streambuf copy-constructible?">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue421.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="421"><a href="lwg-closed.html#421">421</a>. is <code>basic_streambuf</code> copy-constructible?</h3>
<p><b>Section:</b> 31.6.3.2 <a href="https://wg21.link/streambuf.cons">[streambuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The reflector thread starting with c++std-lib-11346 notes that the class
template <code>basic_streambuf</code>, along with <code>basic_stringbuf</code> and <code>basic_filebuf</code>,
is copy-constructible but that the semantics of the copy constructors
are not defined anywhere. Further, different implementations behave
differently in this respect: some prevent copy construction of objects
of these types by declaring their copy ctors and assignment operators
private, others exhibit undefined behavior, while others still give
these operations well-defined semantics.
</p>

<p>
Note that this problem doesn't seem to be isolated to just the three
types mentioned above. A number of other types in the library section
of the standard provide a compiler-generated copy ctor and assignment
operator yet fail to specify their semantics.  It's believed that the
only types for which this is actually a problem (i.e. types where the
compiler-generated default may be inappropriate and may not have been
intended) are locale facets.  See issue <a href="lwg-closed.html#439" title="Should facets be copyable? (Status: NAD)">439</a><sup><a href="https://cplusplus.github.io/LWG/issue439" title="Latest snapshot">(i)</a></sup>.
</p>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote><p>
NAD. Option B is already in the Working Draft.
</p></blockquote>



<p id="res-421"><b>Proposed resolution:</b></p>
<p>
27.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
</p>

<blockquote>
<pre>
basic_streambuf(const basic_streambuf&amp; sb);
basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
</pre>
</blockquote>

<p>Insert after 27.5.2.1, paragraph 2:</p>
<blockquote>
<pre>
basic_streambuf(const basic_streambuf&amp; sb);
</pre>

<p>Constructs a copy of <code>sb</code>.</p>
<p>Postcondtions:</p>
<pre>
                eback() == sb.eback()
                gptr()  == sb.gptr()
                egptr() == sb.egptr()
                pbase() == sb.pbase()
                pptr()  == sb.pptr()
                epptr() == sb.epptr()
                getloc() == sb.getloc()
</pre>

<pre>
basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
</pre>

<p>Assigns the data members of <code>sb</code> to this.</p>

<p>Postcondtions:</p>
<pre>
                eback() == sb.eback()
                gptr()  == sb.gptr()
                egptr() == sb.egptr()
                pbase() == sb.pbase()
                pptr()  == sb.pptr()
                epptr() == sb.epptr()
                getloc() == sb.getloc()
</pre>

<p>Returns: *this.</p>
</blockquote>

<p>27.7.1 [lib.stringbuf]:</p>

<p><b>Option A:</b></p>

<blockquote>
<p>Insert into the <code>basic_stringbuf</code> synopsis in the private section:</p>

<pre>
basic_stringbuf(const basic_stringbuf&amp;);             // not defined
basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
</pre>
</blockquote>

<p><b>Option B:</b></p>

<blockquote>
<p>Insert into the <code>basic_stringbuf</code> synopsis in the public section:</p>

<pre>
basic_stringbuf(const basic_stringbuf&amp; sb);
basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
</pre>

<p>27.7.1.1, insert after paragraph 4:</p>

<pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>

<p>
Constructs an independent copy of <code>sb</code> as if with <code>sb.str()</code>, and with the openmode that <code>sb</code> was constructed with.
</p>

<p>Postcondtions: </p>
<pre>
               str() == sb.str()
               gptr()  - eback() == sb.gptr()  - sb.eback()
               egptr() - eback() == sb.egptr() - sb.eback()
               pptr()  - pbase() == sb.pptr()  - sb.pbase()
               getloc() == sb.getloc()
</pre>

<p>
Note:  The only requirement on <code>epptr()</code> is that it point beyond the initialized range if an 
output sequence exists.  There is no requirement that <code>epptr() - pbase() == sb.epptr() - sb.pbase()</code>.
</p>

<pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
<p>
After assignment the <code>basic_stringbuf</code> has the same state as if it were initially copy constructed 
from <code>sb</code>, except that the <code>basic_stringbuf</code> is allowed to retain any excess capacity it 
might have, which may in turn effect the value of <code>epptr()</code>.
</p>
</blockquote>

<p>27.8.1.1 [lib.filebuf]</p>

<p>Insert at the bottom of the <code>basic_filebuf</code> synopsis:</p>

<blockquote>
<pre>
private:
  basic_filebuf(const basic_filebuf&amp;);             // not defined
  basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
</pre>
</blockquote>
<p><i>[Kona: this is an issue for <code>basic_streambuf</code> itself and for its
  derived classes.  We are leaning toward allowing <code>basic_streambuf</code> to
  be copyable, and specifying its precise semantics.  (Probably the
  obvious: copying the buffer pointers.)  We are less sure whether
  the <code>streambuf</code> derived classes should be copyable.  Howard will
  write up a proposal.]</i></p>


<p><i>[Sydney: Dietmar presented a new argument against <code>basic_streambuf</code>
  being copyable: it can lead to an encapsulation violation. <code>filebuf</code>
  inherits from <code>streambuf</code>. Now suppose you inherit a <code>my_hijacking_buf</code>
  from <code>streambuf</code>. You can copy the <code>streambuf</code> portion of a <code>filebuf</code> to a
  <code>my_hijacking_buf</code>, giving you access to the pointers into the
  <code>filebuf</code>'s internal buffer. Perhaps not a very strong argument, but
  it was strong enough to make people nervous. There was weak
  preference for having <code>streambuf</code> not be copyable. There was weak
  preference for having <code>stringbuf</code> not be copyable even if <code>streambuf</code>
  is. Move this issue to open for now.
]</i></p>


<p><i>[
2007-01-12, Howard:
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a>
recommends protected copy constructor and assignment for <code>basic_streambuf</code> with the same semantics
as would be generated by the compiler.  These members aid in derived classes implementing move semantics.
A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
today as each data member of a <code>basic_streambuf</code> is already both readable and writable by derived
classes via various get/set protected member functions (<code>eback()</code>, <code>setp()</code>, etc.).  Rather
a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
move semantics less tedious and error prone.
]</i></p>




<p><b>Rationale:</b></p>
<p>
27.5.2 [lib.streambuf]: The proposed <code>basic_streambuf</code> copy constructor
and assignment operator are the same as currently implied by the lack
of declarations: public and simply copies the data members.  This
resolution is not a change but a clarification of the current
standard.
</p>

<p>
27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
<code>basic_stringbuf</code> not copyable.  This is likely the status-quo of
current implementations.  B) Reasonable copy semantics of
<code>basic_stringbuf</code> can be defined and implemented.  A copyable
<code>basic_streambuf</code> is arguably more useful than a non-copyable one.  This
should be considered as new functionality and not the fixing of a
defect.  If option B is chosen, ramifications from issue 432 are taken
into account.
</p>

<p>
27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
<code>basic_filebuf</code>.
</p>






</body>
</html>
