<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Concepts for the Standard Library Introduction</title>
</head>

<body>

<p>Document number:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; N2755 = 08-0265<br>
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d" startspan -->2008-09-15<!--webbot bot="Timestamp" endspan i-checksum="12605" --><br>
Project:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Programming Language C++, Library Working Group<br>
Reply-to:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Beman Dawes &lt;bdawes at acm.org&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Douglas Gregor &lt;dgregor at cs.indiana.edu&gt;</p>
<h1>Concepts for the C++0x Standard Library: Chapter 17 -Introduction (Revision 
2)</h1>
<p align="center">Douglas Gregor, Jeremiah Willcock, and Andrew Lumsdaine<br>
Open Systems Laboratory<br>
Indiana University<br>
Bloomington, IN 47405</p>
<p align="center">Beman Dawes<br>
Software Libraries<br>
Onancock, VA 23417-0400</p>
<h2>Introduction</h2>
<p>This document proposes changes to Chapter 17 of the C++ Standard Library to 
enable full use of concepts<a href="#1">[1]</a> throughout the library clauses.</p>
<p>This document is formatted in the same manner as the working draft of the C++ 
standard. Future versions of this document will track the working draft and the 
concepts proposal as they evolve. Proposed changes to the working paper provide 
enough current text to supply context, but only <strike><font color="#FF0000">
red current text with strikethrough</font></strike> is to be deleted, and only
<u><font color="#009A9A">blue-green text with underscore</font></u> is to be 
added, unless editorial comments state otherwise.</p>
<p>The proposed changes involve adding wording to enable library components to 
be specified in terms of the concepts features of the language. The proposal 
does not include removing 
wording that enables library components to be specified in pre-concepts terms. 
Both forms of specification must coexist until such time as all pre-concept 
requirements have been replaced by concept-based requirements.</p>
<p><b><i>Note well:</i></b> This proposal does not reflect changes to clause 17 
that will be required if concepts are applied to clause 27, Input/output 
library. Such changes are deferred until an actual proposal for applying 
concepts to clause 27 is available.</p>
<h2>Revision history</h2>
<p>N2755 is a revision of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2618.html">
N2618</a>. Changes include:</p>
<ul>
  <li>Added &lt;container_concepts&gt; to the list of new headers.</li>
  <li>17.3.1.2 Requirements [structure.requirements], changed &quot;which&quot; to &quot;that&quot; 
  in two places, removed one comma, and moved another comma.</li>
  <li>Struck the section &quot;Phase II Proposed Wording - Disabling Pre-Concepts Specifications&quot; 
  since there is no chance that the entire standard library will be conceptized 
  at one time. The introduction was changed accordingly.</li>
</ul>
<p><i>The LWG Concepts sub-group in San Francisco explicitly decided not to 
grant implementers latitude to replace a concept requirement with a less 
restrictive concept requirement. Such latitude would diminish the ability of 
users to write portable code.</i></p>
<p>N2618 is a revision of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2037.pdf">
N2037</a>. Major changes include:</p>
<ul>
  <li>Proposed wording relative to <i>Working Draft, Standard for Programming 
  Language C++</i>,&nbsp;
  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">
  N2588</a>.</li>
  <li>Proposed wording separated into Phase I and Phase II.</li>
  <li>Proposed changes related to I/O have been removed from this proposal, as 
  there is currently no proposal to apply concepts to clause 27.</li>
</ul>
<h2>Proposed Wording - Enabling Concept based Specifications</h2>
<h4>17.1.14 [defns.narrow.iostream] narrow-oriented iostream classes</h4>
<p>the instantiations of the iostream class templates on the character container 
class char and the default value of <font color="#FF0000"><strike>the traits 
parameter</strike></font><u><font color="#009A9A">any</font><font color="#009A9A"> other parameters</font></u>. 
The traditional iostream classes are regarded as the narrow-oriented iostream 
classes (27.3.1).</p>
<h4>17.1.22 [defns.wide.iostream] wide-oriented iostream classes</h4>
<p>the instantiations of the iostream class templates on the character container 
class wchar_t and the default value of <font color="#FF0000"><strike>the traits 
parameter (27.3.2)</strike></font><u><font color="#009A9A">any other parameters</font></u>.</p>
<h4>17.3.1.2 Requirements [structure.requirements]</h4>
<p>The library can be extended by a C++ program. Each clause, as applicable, 
describes the requirements that such extensions must meet. Such extensions are 
generally one of the following:</p>
<blockquote>
  <p> Template arguments<br>
   Derived classes<br>
   Containers, iterators, and/or algorithms that meet an interface convention</p>
</blockquote>
<p>The string and iostreams components use an explicit representation of 
operations required of template arguments. They use a class template char_traits 
to define these constraints.</p>
<p>Interface convention requirements are stated as generally as possible. 
Instead of stating class X has to define a member function operator++(), the 
interface requires for any object x of class X, ++x is defined. That is, 
whether the operator is a member is unspecified.</p>
<p>Requirements are stated in terms of well-defined expressions<font color="#FF0000"><strike>, which</strike></font>
<font color="#0099CC"><u>that</u></font> define 
valid terms of the types that satisfy the requirements<u><font color="#009A9A">, 
or concepts that define capabilities of the types that satisfy the 
requirements</font></u>. For every set of <u><font color="#009A9A">well-defined 
expression</font></u> requirements there is a table that specifies an initial 
set of the valid expressions and their semantics<font color="#FF0000"><strike> (20.1.2, 23.1, 24.1)</strike></font>. <u>
<font color="#009A9A">For every set of concept requirements there is a concept 
that specifies the requirements and their semantics (20.1.2, 23.1, 24.1).</font></u> 
Any generic algorithm (clause 25) that uses the<u><font color="#009A9A"> 
well-defined expression</font><font color="#0099CC"> </font></u>requirements is described in terms of the 
valid expressions for its formal type parameters. <u><font color="#009A9A">Any 
generic algorithm (clause 25) that uses concepts places requirements on its 
formal type parameters.</font></u></p>
<p>Template argument requirements are sometimes referenced by name. See 
17.3.2.1.</p>
<p>In some cases the semantic requirements are presented as C++ code. Such code 
is intended as a specification of equivalence of a construct to another 
construct, not necessarily as the way the construct must be implemented.150)</p>
<h4>17.3.1 Structure of each subclause [structure]</h4>
<p><font face="NimbusRomNo9L-Regu">The elements of the C++ Standard Library are 
declared or defined (as appropriate) in a header.</font><sup><font face="Times New Roman">167)</font></sup></p>
<p>The C++ Standard Library provides <strike><font color="#FF0000">43</font></strike><u><font color="#009A9A">47</font></u> 
C++ headers, as shown in Table 13.</p>
<h4>17.3.1 Structure of each subclause [structure], to Table 13: C++ Library 
Headers, add:</h4>
<blockquote>
  <p><u><font color="#009A9A"><code>&lt;concepts&gt;<br>
  &lt;container_concepts&gt;<br>
  &lt;iterator_concepts&gt;<br>
  &lt;numeric_concepts&gt;</code></font></u></p>
</blockquote>
<h4>17.4.1.1 Library contents [lib.contents]</h4>
<p>The C++ Standard Library provides definitions for the following types of 
entities: Macros, Values, Types, <u><font color="#009A9A">Concepts, Concept 
maps,</font></u> Templates, Classes, Functions, Objects.</p>
<h4 ALIGN="LEFT">17.4.3.1 Namespace std [namespace.std]</h4>
<p ALIGN="LEFT">The behavior of a C++ program is undefined if it adds 
declarations or definitions to namespace std or to a namespace within namespace 
std unless otherwise specified. A program may add<font color="#0099CC"> </font>
<font color="#009A9A"> <u>a 
concept map for any standard library concept or</u></font><font color="#0099CC"> </font>a template 
specialization for any standard library template to namespace std only if the 
declaration depends on a user-defined type of external linkage and the 
specialization meets the standard library requirements for the original template
<u><font color="#009A9A">and is not explicitly prohibited</font></u>.</p>
<h2>Bibliography</h2>
<p>[<a name="1">1</a>] D.&nbsp;Gregor, B.&nbsp;Stroustrup, J.&nbsp;Siek, J.&nbsp;Widman. Proposed 
Wording for Concepts (Revision 5). Technical Report N2617=08-0127, ISO/IEC JTC 1, Information Technology, Subcommittee SC 22, 
Programming Language C++, May 2008.</p>

<hr>

</body>

</html>