From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-05-07 07:05:30
The C++ standards committee met last week in Copenhagen. The Library
Working Group (LWG) is moving forward with preliminaries for a Library
Technical Report (TR). The necessary ISO paperwork is underway.
(A type 2 Technical Report is non-normative. Library suppliers are not
obligated to implement a TR, but it provides an standard specification for
those who do choose to implement it. The TR also serves to notify the C++
community of future direction; the intent is to include the contents of the
TR in a future standard.)
(The follow is my interpretation of the LWG's direction, so is subject to
change. Where I give examples, they are examples that came up in the LWG
* The time line for the TR is two years, with the intent to continue the
process on an ongoing basis, presumably by continuing work on the next TR
even as the first one is completed.
* Libraries which cannot be implemented on all platforms will be
accepted. For example, threads or TCP/IP. Such libraries will simply be
non-normative even in a future standard (and thus never required), rather
than the standard trying to dictate when a vendor is required to supply the
library. Libraries may be supplied in fully functional form, not at all, or
as a non-functional stub. (Non-functional implementations would be useful
for a threads library, for example, so that other libraries could use it
without change even on a platform without threads.) There will be a way
(possibly via macro) to tell which form (functional/none/non-functional) is
supplied by a given implementation.
* Primary interest is for proposals in the following areas:
-- Filling in gaps in the current standard library.
-- Text processing. For example, regular expressions.
-- Numerics. (No examples were given, IIRC.)
-- Graphics. Just the ability to draw, not a GUI.
-- System Programming. Access to operating system facilities,
such as threads, directories, etc.
-- Networking. For example, TCP/IP, sockets.
-- Language bindings. Particularly tools which support
bindings in general, rather than bindings to a particular
* For a proposal to be considered, it must be well-formed, represent
existing practice (with reference implementation), and not break existing
There was some discussion of where proposals might come from. Boost was
mentioned, of course. (The bulk of the LWG are Boost members, and the
remainder tend to be very supportive of Boost.) The only other mention was
a group of library suppliers who may propose hash tables and singly linked
lists based on their current implementations.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk