<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1001: Pointers, concepts and headers</title>
<meta property="og:title" content="Issue 1001: Pointers, concepts and headers">
<meta property="og:description" content="C++ library issue. Status: NAD Concepts">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1001.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_Concepts">NAD Concepts</a> status.</em></p>
<h3 id="1001"><a href="lwg-closed.html#1001">1001</a>. Pointers, concepts and headers</h3>
<p><b>Section:</b> 16 <a href="https://wg21.link/library">[library]</a> <b>Status:</b> <a href="lwg-active.html#NAD_Concepts">NAD Concepts</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-10 <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#NAD Concepts">NAD Concepts</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 78</b></p>

<p>
Related to <a href="lwg-closed.html#1063" title="03 iterator compatibilty (Status: NAD Concepts)">1063</a><sup><a href="https://cplusplus.github.io/LWG/issue1063" title="Latest snapshot">(i)</a></sup>.
</p>

<p>
This is effectively an extension of LWG issue <a href="lwg-defects.html#343" title="Unspecified library header dependencies (Status: Resolved)">343</a><sup><a href="https://cplusplus.github.io/LWG/issue343" title="Latest snapshot">(i)</a></sup>.
</p>
<p>
We know there is an increasing trend (encouraged by conformance testers and
some users) that each library header should supply no more than required to
satisfy the synopsis in the standard.  This is typically achieved by
breaking larger headers into smaller subsets, and judicious use of forward
declarations.
</p>
<p>
If we apply this policy to C++0x (per
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>)
it will be very surprising for
people using library algorithms over ranges defined by pointers that they
must <code>#include &lt;iterator_concepts&gt;</code> for their code to compile again.  That is
because pointers do not satisfy any of the iterator concepts without the
<code>concept_map</code> supplied in this header.
</p>
<p>
Therefore, I suggest we should require all library headers that make use of
iterator concepts are specifically required to <code>#include &lt;iterator_concepts&gt;</code>.
</p>
<p>
At a minimum, the list of headers would be: (assuming all are constrained by
concepts)
</p>
<blockquote><pre>
algorithm
array
deque
forward_list
initializer_list
iterator
locale
list
map
memory          // if <a href="lwg-closed.html#1029" title="Specialized algorithms for memory management need to be concept-constrained templates (Status: NAD Concepts)">1029</a><sup><a href="https://cplusplus.github.io/LWG/issue1029" title="Latest snapshot">(i)</a></sup> is adopted
memory_concepts
numeric
random
regex
set
string
tuple
unordered_map
unordered_set
utility
vector
</pre></blockquote>

<p><i>[
Ganesh adds:
]</i></p>


<blockquote>
<p>
The same problems exists for <code>&lt;memory_concepts&gt;</code> and
<code>&lt;container_concepts&gt;</code>.
</p>
<p>
In order to compile <code>&lt;vector&gt;</code> you just need the
definitions of the concepts in <code>&lt;memory_concepts&gt;</code>, the
concept maps defined there are not necessary. Yet, from the user point
of view, if the concept map template for <code>AllocatableElement</code> are
not in scope, <code>&lt;vector&gt;</code> is pretty useless. Same for
<code>&lt;tuple&gt;</code> and <code>ConstructibleWithAllocator</code>.
</p>
<p>
Similarly, <code>&lt;queue&gt;</code> is not very useful if the concept map
template for <code>QueueLikeContainer</code> is not in scope, although the
definition of concept alone is theoretically sufficient.
</p>
<p>
There's a pattern here: if a concept has concept maps "attached", they
should never be separated.
</p>
</blockquote>

<p><i>[
Beman provided the proposed resolution for the May 2009 mailing. He 
comments:
]</i></p>


<blockquote>

<p>Initially I tried to specify exactly what header should include what other 
headers. This was verbose, error prone, hard to maintain, and appeared to add 
little value compared to just stating the general rule.</p>

</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Pete believes the proposed wording overconstrains implementers.
Instead of specifying the mechanism,
he prefers a solution that spells out what needs to be declared,
rather than how those declarations are to be provided,
e.g.,
</p>
<blockquote><p>
A C++ header shall provide the names
that are required to be defined in that header.
</p></blockquote>
<p>
Bill suggests approaching the wording from a programmer's perspective.
We may want to consider promising that certain widely-used headers
(e.g., the concept headers) are included when needed by other headers.
He feels, however, there is nothing broken now,
although we may want to consider "something nicer."
</p>
<p>
Move to Open status.
</p>

</blockquote>

<p><i>[
2009-06-16 Beman updated the proposed resolution:
]</i></p>


<blockquote>
  <ul>
    <li>The mechanism is no longer specified, as requested in Batavia.</li>
    <li>The footnote has been removed since it specified mechanism and also did 
    not reflect existing practice.</li>
    <li>A sentence was added that makes it clear that the existing practice is 
    permitted.</li>
  </ul>
</blockquote>

<p><i>[
2009-07-15 Beman updated the proposed resolution:
]</i></p>


<p><i>[
2009-07-17 Beman updated the proposed resolution based on feedback from the LWG in Frankfurt:
]</i></p>


<blockquote>
<ul>
<li>Strike two pieces of text considered unnecessary.</li>
<li>Change &quot;definitions&quot; to &quot;declarations and definitions&quot; in two places.</li>
<li>Wording tightened slightly.</li>
</ul>
</blockquote>

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


<blockquote>
<p>
Revised Proposed Resolution:
</p>
<p>
A C++ header may include other C++ headers. A C++ header shall provide
the declarations and definitions that appear in its synopsis (3.2
[basic.def.odr]). A C++ header shown in its synopsis as including other
C++ headers shall provide the declarations and definitions that appear
in the synopses of those other headers.
</p>
<p>
Alisdair: Does this address the BSI comment?
<p/>
Beman: There were several overlapping comments. I tried to handle them
all with one resolution.
<p/>
Alisdair: I'd prefer to see this closed as NAD and have this resolution
be the subject of some other, new issue.
<p/>
Move to NAD Concepts. Howard to open a new issue (<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>) in Ready state with the
Proposed Resolution above. Beman will write up a discussion for the new
issue.
</p>
</blockquote>



<p id="res-1001"><b>Proposed resolution:</b></p>
<p><i>Change 16.4.6.2 <a href="https://wg21.link/res.on.headers">[res.on.headers]</a>, Headers, paragraph 1, as indicated:</i></p>

<blockquote>

<p>
A C++ header may include other C++
headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
the declarations and definitions that appear in its synopsis
(6.3 <a href="https://wg21.link/basic.def.odr">[basic.def.odr]</a>). A C++ header shown in its synopsis as including 
other C++ headers shall provide the same declarations and definitions as
if those other headers were included.</ins>
</p>

  <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains 
  any needed definition (3.2).</del></p>
</blockquote>






</body>
</html>
