Document number: N2618=08-0128
Date: 2008-05-13
Project:
Programming Language C++, Library Working Group
Reply-to:
Beman Dawes <bdawes at acm.org>
Douglas Gregor <dgregor at cs.indiana.edu>
Douglas Gregor, Jeremiah Willcock, and Andrew Lumsdaine
Open Systems Laboratory
Indiana University
Bloomington, IN 47405
Beman Dawes
Software Libraries
Onancock, VA 23417-0400
This document proposes changes to Chapter 17 of the C++ Standard Library to enable full use of concepts[1] throughout the library clauses.
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
red current text with strikethrough is to be deleted, and only
blue-green text with underscore is to be
added, unless editorial comments state otherwise. All
editorial comments will have a gray
background.
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.
Note well: 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.
This proposal is a revision of N2037. Major changes include:
the instantiations of the iostream class templates on the character container
class char and the default value of the traits
parameterany other parameters.
The traditional iostream classes are regarded as the narrow-oriented iostream
classes (27.3.1).
the instantiations of the iostream class templates on the character container
class wchar_t and the default value of the traits
parameter (27.3.2)any other parameters.
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:
— Template arguments
— Derived classes
— Containers, iterators, and/or algorithms that meet an interface convention
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.
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.
Requirements are stated in terms of well-defined expressions, which define
valid terms of the types that satisfy the requirements
or concepts, which define capabilities of the types that satisfy the
requirements. For every set of well-defined
expression requirements there is a table that specifies an initial
set of the valid expressions and their semantics (20.1.2, 23.1, 24.1).
For every set of concept requirements there is a concept
that specifies the requirements and their semantics (20.1.2, 23.1, 24.1).
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. Any
generic algorithm (clause 25) that uses concepts places requirements on its
formal type parameters.
Template argument requirements are sometimes referenced by name. See 17.3.2.1.
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)
The elements of the C++ Standard Library are declared or defined (as appropriate) in a header.167)
The C++ Standard Library provides 4346
C++ headers, as shown in Table 13.
<concepts>
<iterator_concepts>
<numeric_concepts>
The C++ Standard Library provides definitions for the following types of entities: Macros, Values, Types, Concepts, Concept maps, Templates, Classes, Functions, Objects.
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 a concept map for any standard library concept or 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 and is not explicitly prohibited.
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:
— Template arguments
— Derived classes
— Containers, iterators, and/or algorithms that meet an interface convention
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.
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.
Requirements are stated in terms of
well-defined expressions, which define valid terms of the types that satisfy the
requirements or concepts, which define capabilities of the types
that satisfy the requirements. For every set of
well-defined expression requirements there is a table that specifies an initial
set of the valid expressions and their semantics.
For every set of concept
requirements there is a concept that specifies the requirements and their
semantics (20.1.2, 23.1, 24.1). 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.
Any generic algorithm (clause 25) that uses concepts places requirements on its
formal type parameters.
Template argument requirements are sometimes
referenced by name. See 17.3.2.1.
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)
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.
154) Examples from 20.1 include:
EqualityComparable, LessThanComparable, CopyConstructable, etc. Examples from
24.1 include: InputIterator, ForwardIterator, Function, Predicate, etc.
[1] D. Gregor, B. Stroustrup, J. Siek, J. 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.