Doc. no.: J16/01-0028 = WG21 N1314
Date: 17 May 2001
Project: Programming Language C++
Reply to: Matt Austern <firstname.lastname@example.org>
Notes on Standard Library Extensions
At the Copenhagen meeting, J16 and WG21 passed a motion to request a
new work item: a technical report of type 2 on standard library
extensions, an initial version of which should be completed by 2003.
This technical report will not be normative, but the items in it may
be considered for standardization in a future revision of the
standard. This is particularly important because preliminary
discussion about "C++0x" is already underway; it is likely that a
future revision of C++ will primarily involve expansion of the
standard library, with very few core language changes.
This paper is a preliminary outline of what kinds of extensions the
committee will consider, and how it will do so. Its purpose is to
summarize some of the Copenhagen discussions, and to stimulate further
discussion. In some cases I propose questions without proposing an
The terms of the proposed work item give the committee broad
discretion on what to include in the TR. For the most part, we expect
that the TR will consist of specific library extensions, in form
suitable for eventual inclusion in a future standard. It may also be
useful to have a discussion of versioning: if there are changes to the
standard library, how can source and binary incompatibility be
minimized? Can the namespace mechanism be made to help?
At this early stage, the library working group was reluctant to
identify any possible directions that would definitely be ruled out.
- Both "pure" extensions (new library components that don't affect
the existing standard library) and "impure" extensions (changing
existing components to add functionality) may be considered. Pure
extensions are preferred, but impure extensions are not necessarily
ruled out. For example, it might be useful to think about adding
finer-grained iterator categories.
- Library extensions will be considered even if they cannot be
implemented on every platform. For example: there are platforms
that can support a hosted C++ implementation, but that do not
support threads or network communication. Libraries for networking
and multithreading will be considered, even though they can't be
implemented on such platform.
A future revision of the standard will have to consider what this
means: how can we make normative requirements that are not
universally implementable? It may be necessary to introduce a
notion of optional components, as the POSIX standard has in some
cases. (There was widespread lack of support for the idea of
"stub" APIs that fail whenever they're used.) However, since a
type 2 technical report is not normative, there is no need to
decide on the exact details yet: everything in a TR is optional.
Instead of identifying areas that will not be considered, it is
desirable to identify areas that are of particular interest and that
the committee intends to focus on. It's better to make changes with
specific goals in mind than to make them randomly. A possible list
A. Filling gaps, and removing obvious embarrassments
Obvious candidates include hash tables and reference-counted
pointers. We can learn about more such candidates by looking at
the library issues that the library working group has closed as
"NAD Future", and by talking to people who teach C++ and who can
tell us about ways in which the library is inconsistent with
B. Coordination with other standardization efforts
The most important standardization effort we should coordinate
with, of course, is C. C99 has added a number of library
components that were not present in C90; all of them should be
considered as possible C++ extensions. One obvious example is
C99's <inttypes.h> and <stdint.h>.
Other standardization bodies whose work is directly relevant to
the C++ library include WG20 (internationalization) and POSIX.
C. Additional components for infrastructure
Examples of "infrastructure" components include pattern
implementation classes, policy classes, and traits classes.
D. Better support for specific important application domains
Such domains might include:
- text processing
- system programming
- language bindings, and multi-language programming
The participation of domain experts would be essential.
CRITERIA FOR EVALUATING PROPOSALS
As a general rule, the standardization committee will not attempt to
design components from scratch: in most cases we will expect to
evaluate and refine proposals. We will need to develop criteria for
A proposal is not just a suggestion, or an item on a wish list: "We
should add hash tables" is not a proposal. A proposal should be a
well thought out design, and should include specific text that would
be suitable for a standard. It should be stylistically consistent
with the existing standard library. Ideally it should include a
reference implementation, and it should include a discussion of the
reasoning behind the design decisions.
A proposal must make it clear whether the library can be implemented
in standard C++ (as defined in ISO/IEC 14882:1998, is desirable).
Proposals that maintain source and binary compatibility, and that can
be implemented in standard C++ are to be preferred: they are more
immediately useful, and the committee's goal is to minimize core
language changes in future revisions of the standard. If it turns out
that certain kinds of useful library techniques are not possible
within the confines of standard C++, however, that fact could be
valuable information. It might be useful for the TR to explore the
boundary between what can and can't be implemented in standard C++.
Proposals can be submitted by committee members, or through national
bodies. Additionally, the commitee may wish to set up other channels,
much as we have set up informal channels for submitting defect reports
via the Usenet newsgroup comp.std.c++. We may wish to ask the
moderators of comp.std.c++, or comp.lang.c++.moderated, to act as an
initial filter for library extension proposals. We may also wish to
ask BOOST to act as such a filter.
Regardless of how proposals are submitted, the committee should make
the process as open as possible and should make it easy for people who
aren't on the committee to submit proposals. Two concrete suggestions
- Create model proposal, so people can see what a well-formed
proposal looks like.
- Develop some form of interactive submission, so proposers can
get some help before submission is final. This implies doing
some work between meetings: a six-month feedback cycle is too