<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; N2618=08-0128<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-05-13<!--webbot bot="Timestamp" endspan i-checksum="12345" --><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 
1)</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. All 
editorial comments will <span style="background-color: #C0C0C0">have a gray 
background</span>.</p>
<p>The proposed changes involve adding wording to enable library components to 
be specified in terms of the concepts features of the language, and removing 
wording that enabled library components to be specified in pre-concepts terms. 
In the event that application of concepts to all components of the standard 
library does not occur at a single committee meeting, both forms of 
specification must coexist. The required changes are therefore specified in two 
phases, so they can be voted into the working paper at separate meetings if need 
be.</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>This proposal 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>Phase I 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, which define 
valid terms of the types that satisfy the requirements<u><font color="#009A9A"> 
or concepts, which 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">46</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;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>Phase II Proposed Wording - Disabling Pre-Concepts Specifications</h2>
<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><strike><font color="#FF0000">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.</font></strike></p>
<p><strike><font color="#FF0000">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.</font></strike></p>
<p>Requirements are stated in terms of <strike><font color="#FF0000">
well-defined expressions, which define valid terms of the types that satisfy the 
requirements or</font></strike> concepts, which define capabilities of the types 
that satisfy the requirements. <strike><font color="#FF0000">For every set of 
well-defined expression requirements there is a table that specifies an initial 
set of the valid expressions and their semantics.</font></strike> 
For every set of <strike><font color="#FF0000">concept</font></strike> 
requirements there is a concept that specifies the requirements and their 
semantics (20.1.2, 23.1, 24.1). <strike><font color="#FF0000">Any generic 
algorithm (clause 25) that uses the well-defined expression requirements is 
described in terms of the valid expressions for its formal type parameters.</font></strike> 
Any generic algorithm (clause 25) that uses concepts places requirements on its 
formal type parameters.</p>
<p><strike><font color="#FF0000">Template argument requirements are sometimes 
referenced by name. See 17.3.2.1.</font></strike></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.2.1 Type descriptions [type.descriptions]</h4>
<p><strike><font color="#FF0000">The Requirements subclauses may describe names 
that are used to specify constraints on template arguments.154) These names are 
used in library clauses to describe the types that may be supplied as arguments 
by a C++ program when instantiating template components from the library.</font></strike></p>
<p><strike><font color="#FF0000">154) Examples from 20.1 include: 
EqualityComparable, LessThanComparable, CopyConstructable, etc. Examples from 
24.1 include: InputIterator, ForwardIterator, Function, Predicate, etc.</font></strike></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>