<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 194: rdbuf() functions poorly specified</title>
<meta property="og:title" content="Issue 194: rdbuf() functions poorly specified">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue194.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="194"><a href="lwg-closed.html#194">194</a>. rdbuf() functions poorly specified</h3>
<p><b>Section:</b> 31.5.4 <a href="https://wg21.link/ios">[ios]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1999-09-07 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>In classic iostreams, base class ios had an rdbuf function that returned a
pointer to the associated streambuf. Each derived class had its own rdbuf
function that returned a pointer of a type reflecting the actual type derived
from streambuf. Because in ARM C++, virtual function overrides had to have the
same return type, rdbuf could not be virtual.</p>
<p>In standard iostreams, we retain the non-virtual rdbuf function design, and
in addition have an overloaded rdbuf function that sets the buffer pointer.
There is no need for the second function to be virtual nor to be implemented in
derived classes.</p>
<p>Minor question: Was there a specific reason not to make the original rdbuf
function virtual?</p>
<p>Major problem: Friendly compilers warn about functions in derived classes
that hide base-class overloads. Any standard implementation of iostreams will
result in such a warning on each of the iostream classes, because of the
ill-considered decision to overload rdbuf only in a base class.</p>
<p>In addition, users of the second rdbuf function must use explicit
qualification or a cast to call it from derived classes. An explicit
qualification or cast to basic_ios would prevent access to any later overriding
version if there was one.</p>
<p>What I'd like to do in an implementation is add a using- declaration for the
second rdbuf function in each derived class. It would eliminate warnings about
hiding functions, and would enable access without using explicit qualification.
Such a change I don't think would change the behavior of any valid program, but
would allow invalid programs to compile:</p>
<blockquote>
  <pre> filebuf mybuf;
 fstream f;
 f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
</blockquote>
<p>I'd like to suggest this problem as a defect, with the proposed resolution to
require the equivalent of a using-declaration for the rdbuf function that is not
replaced in a later derived class. We could discuss whether replacing the
function should be allowed.</p>


<p><b>Rationale:</b></p>
<p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
class <code> rdbuf()</code> and derived class <code>rdbuf()</code>. The derived
class <code> rdbuf()</code> always returns the original streambuf, whereas the base class
<code> rdbuf()</code> will return the "current streambuf" if that has been changed by the variant you mention.</p>

<p>Permission is not required to add such an extension.  See 
16.4.6.5 <a href="https://wg21.link/member.functions">[member.functions]</a>.</p>




</body>
</html>
