Document number:       N2755 = 08-0265
Date:                            2008-09-15
Project:                        Programming Language C++, Library Working Group
Reply-to:                      Beman Dawes <bdawes at>
                                    Douglas Gregor <dgregor at>

Concepts for the C++0x Standard Library: Chapter 17 -Introduction (Revision 2)

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.

Revision history

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:

Proposed Wording - Enabling Concept based Specifications

17.1.14 [defns.narrow.iostream] narrow-oriented iostream classes

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).

17.1.22 [defns.wide.iostream] wide-oriented iostream classes

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. Requirements [structure.requirements]

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

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)

17.3.1 Structure of each subclause [structure]

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.

17.3.1 Structure of each subclause [structure], to Table 13: C++ Library Headers, add:

<numeric_concepts> Library contents [lib.contents]

The C++ Standard Library provides definitions for the following types of entities: Macros, Values, Types, Concepts, Concept maps, Templates, Classes, Functions, Objects. Namespace std [namespace.std]

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.