Document number: N2755 = 08-0265
Date: 2008-09-15
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.
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.
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.
N2755 is a revision of N2618. Changes include:
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.
N2618 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
that define
valid terms of the types that satisfy the requirements,
or concepts that 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 4347
C++ headers, as shown in Table 13.
<concepts>
<container_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.
[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.