<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 343: Unspecified library header dependencies</title>
<meta property="og:title" content="Issue 343: Unspecified library header dependencies">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue343.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#Resolved">Resolved</a> status.</em></p>
<h3 id="343"><a href="lwg-defects.html#343">343</a>. Unspecified library header dependencies</h3>
<p><b>Section:</b> 16 <a href="https://wg21.link/library">[library]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-10-09 <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#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The synopses of the C++ library headers clearly show which names are
required to be defined in each header. Since in order to implement the
classes and templates defined in these headers declarations of other
templates (but not necessarily their definitions) are typically
necessary the standard in 17.4.4, p1 permits library implementers to
include any headers needed to implement the definitions in each header.
</p>

<p>
For instance, although it is not explicitly specified in the synopsis of
<code>&lt;string&gt;</code>, at the point of definition of the <code>std::basic_string</code> template
the declaration of the <code>std::allocator</code> template must be in scope. All
current implementations simply include <code>&lt;memory&gt;</code> from within <code>&lt;string&gt;</code>,
either directly or indirectly, to bring the declaration of
<code>std::allocator</code> into scope.
</p>

<p>
Additionally, however, some implementation also include <code>&lt;istream&gt;</code> and
<code>&lt;ostream&gt;</code> at the top of <code>&lt;string&gt;</code> to bring the declarations of
<code>std::basic_istream</code> and <code>std::basic_ostream</code> into scope (which are needed
in order to implement the string inserter and extractor operators
(21.3.7.9 [lib.string.io])). Other implementations only include
<code>&lt;iosfwd&gt;</code>, since strictly speaking, only the declarations and not the
full definitions are necessary.
</p>

<p>
Obviously, it is possible to implement <code>&lt;string&gt;</code> without actually
providing the full definitions of all the templates <code>std::basic_string</code>
uses (<code>std::allocator</code>, <code>std::basic_istream</code>, and <code>std::basic_ostream</code>).
Furthermore, not only is it possible, doing so is likely to have a
positive effect on compile-time efficiency.
</p>

<p>
But while it may seem perfectly reasonable to expect a program that uses
the <code>std::basic_string</code> insertion and extraction operators to also
explicitly include <code>&lt;istream&gt;</code> or <code>&lt;ostream&gt;</code>, respectively, it doesn't seem
reasonable to also expect it to explicitly include <code>&lt;memory&gt;</code>. Since
what's reasonable and what isn't is highly subjective one would expect
the standard to specify what can and what cannot be assumed.
Unfortunately, that isn't the case.
</p>

<p>The examples below demonstrate the issue.</p>

<p>Example 1:</p>

<p>It is not clear whether the following program is complete:</p>

<pre>
#include &lt;string&gt;

extern std::basic_ostream&lt;char&gt; &amp;strm;

int main () {
    strm &lt;&lt; std::string ("Hello, World!\n");
}
</pre>    

<p>or whether one must explicitly include <code>&lt;memory&gt;</code> or
<code>&lt;ostream&gt;</code> (or both) in addition to <code>&lt;string&gt;</code> in order for
the program to compile.</p>


<p>Example 2:</p>

<p>Similarly, it is unclear whether the following program is complete:</p>

<pre>
#include &lt;istream&gt;

extern std::basic_iostream&lt;char&gt; &amp;strm;

int main () {
    strm &lt;&lt; "Hello, World!\n";
}
</pre>

<p>
or whether one needs to explicitly include <code>&lt;ostream&gt;</code>, and
perhaps even other headers containing the definitions of other
required templates:</p>

<pre>
#include &lt;ios&gt;
#include &lt;istream&gt;
#include &lt;ostream&gt;
#include &lt;streambuf&gt;

extern std::basic_iostream&lt;char&gt; &amp;strm;

int main () {
    strm &lt;&lt; "Hello, World!\n";
}
</pre>

<p>Example 3:</p>

<p>Likewise, it seems unclear whether the program below is complete:</p>
<pre>
#include &lt;iterator&gt;

bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
{
    return a == b;
}

int main () { }
</pre>

<p>or whether one should be required to include <code>&lt;istream&gt;</code>.</p>

<p>There are many more examples that demonstrate this lack of a
requirement.  I believe that in a good number of cases it would be
unreasonable to require that a program explicitly include all the
headers necessary for a particular template to be specialized, but I
think that there are cases such as some of those above where it would
be desirable to allow implementations to include only as much as
necessary and not more.</p>

<p><i>[
post Bellevue:
]</i></p>


<blockquote><p>
Position taken in prior reviews is that the idea of a table of header
dependencies is a good one. Our view is that a full paper is needed to
do justice to this, and we've made that recommendation to the issue
author.
</p></blockquote>

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


<blockquote><p>
Resolved. Handled by LWG <a href="lwg-defects.html#1178" title="Header dependencies (Status: C++11)">1178</a><sup><a href="https://cplusplus.github.io/LWG/issue1178" title="Latest snapshot">(i)</a></sup>.
</p></blockquote>



<p id="res-343"><b>Proposed resolution:</b></p>
<p>
For every C++ library header, supply a minimum set of other C++ library
headers that are required to be included by that header. The proposed
list is below (C++ headers for C Library Facilities, table 12 in
17.4.1.2, p3, are omitted):
</p>

<pre>
+------------+--------------------+
| C++ header |required to include |
+============+====================+
|&lt;algorithm&gt; |                    |
+------------+--------------------+
|&lt;bitset&gt;    |                    |
+------------+--------------------+
|&lt;complex&gt;   |                    |
+------------+--------------------+
|&lt;deque&gt;     |&lt;memory&gt;            |
+------------+--------------------+
|&lt;exception&gt; |                    |
+------------+--------------------+
|&lt;fstream&gt;   |&lt;ios&gt;               |
+------------+--------------------+
|&lt;functional&gt;|                    |
+------------+--------------------+
|&lt;iomanip&gt;   |&lt;ios&gt;               |
+------------+--------------------+
|&lt;ios&gt;       |&lt;streambuf&gt;         |
+------------+--------------------+
|&lt;iosfwd&gt;    |                    |
+------------+--------------------+
|&lt;iostream&gt;  |&lt;istream&gt;, &lt;ostream&gt;|
+------------+--------------------+
|&lt;istream&gt;   |&lt;ios&gt;               |
+------------+--------------------+
|&lt;iterator&gt;  |                    |
+------------+--------------------+
|&lt;limits&gt;    |                    |
+------------+--------------------+
|&lt;list&gt;      |&lt;memory&gt;            |
+------------+--------------------+
|&lt;locale&gt;    |                    |
+------------+--------------------+
|&lt;map&gt;       |&lt;memory&gt;            |
+------------+--------------------+
|&lt;memory&gt;    |                    |
+------------+--------------------+
|&lt;new&gt;       |&lt;exception&gt;         |
+------------+--------------------+
|&lt;numeric&gt;   |                    |
+------------+--------------------+
|&lt;ostream&gt;   |&lt;ios&gt;               |
+------------+--------------------+
|&lt;queue&gt;     |&lt;deque&gt;             |
+------------+--------------------+
|&lt;set&gt;       |&lt;memory&gt;            |
+------------+--------------------+
|&lt;sstream&gt;   |&lt;ios&gt;, &lt;string&gt;     |
+------------+--------------------+
|&lt;stack&gt;     |&lt;deque&gt;             |
+------------+--------------------+
|&lt;stdexcept&gt; |                    |
+------------+--------------------+
|&lt;streambuf&gt; |&lt;ios&gt;               |
+------------+--------------------+
|&lt;string&gt;    |&lt;memory&gt;            |
+------------+--------------------+
|&lt;strstream&gt; |                    |
+------------+--------------------+
|&lt;typeinfo&gt;  |&lt;exception&gt;         |
+------------+--------------------+
|&lt;utility&gt;   |                    |
+------------+--------------------+
|&lt;valarray&gt;  |                    |
+------------+--------------------+
|&lt;vector&gt;    |&lt;memory&gt;            |
+------------+--------------------+
</pre>


<p><b>Rationale:</b></p>
<p>The portability problem is real.  A program that works correctly on
one implementation might fail on another, because of different header
dependencies.  This problem was understood before the standard was
completed, and it was a conscious design choice.</p>
<p>One possible way to deal with this, as a library extension, would
be an <code>&lt;all&gt;</code> header.</p>

<p>
Hinnant:  It's time we dealt with this issue for C++0X.  Reopened.
</p>







</body>
</html>
