Doc. no.: N1752=05-0012
Date:     2005-01-17
Project:  Programming Language C++
Reply to: Matt Austern <austern@apple.com>

C++0x Standard Library wishlist (revision 3)

This is a list of suggested additions to the standard C++ library for the next version of C++ ("C++0x").

This list is intended as a stimulus to further work. Some of the items on this list already have one or more concrete proposals associated with them, others are vague hopes, and most are somewhere in between. Similarly, the scope of these items extend from minor changes in an existing interface to major research projects.

I have listed a name or names for each item, and, if relevant, I have listed a paper or papers describing the idea. These ideas are not necessarily supported by anyone other than the person who suggested them, and you should not assume that any particular item will make it into C++0x. The items in this list are in no particular order.

The wish list

Formatted container output

Requester: Dave Abrahams
Paper:

Simple and uniform display mechanism for arbitrary ordered lists. (Arrays, STL containers, pairs, tuples, etc.) cout << x should "just work" for such types.

Infinite-precision integer arithmetic

Requester: Maarten Kronenburg, Bjarne Stroustrup, Matt Austern, others
Paper: N1718, "A Proposal to add the Infinite Precision Integer and Rational to the C++ Standard Library", M. J. Kronenburg.

Uniform use of std::string

Requester: Bjarne Stroustrup
Paper:

String versions of all (or) most functions that take C-style strings (e.g. filestream constructors)

Simple numeric access

Requester: Bjarne Stroustrup
Paper:

Simple functions for extracting int and floating-point values out of a string

A richer `std::string` interface

Requester: unknown
Paper:

Better member functions in string template class eg. trimming, upper/lower case conversion etc.

Threads

Requester: Bill Kempf, Bjarne Stroustrup, Andrei Alexandrescu, others
Paper:

Sockets

Requester:Bjarne Stroustrup
Paper:

Explicit support for Unicode

Requester: Matt Austern
Paper:

An XML parser and generator library

Requester: Bjarne Stroustrup
Paper:

Constructive reals

Requester: Bjarne Stroustrup, Hans Boehm
Paper:

"Infinite precision" reals.

GUI

Requester: Bjarne Stroustrup
Paper:

Some form of simple graphic/GUI library (possibly a simple interface to the simpler parts of larger libraries)—a recurent theme.

Random access to files

Requester: Bjarne Stroustrup
Paper:

a facility for random-access to files; maybe a form of random-access iterators for filestreams

Safe STL

Requester: Bjarne Stroustrup
Paper:

a range checked version of standard containers/iterators and algorithms

Filesystem access

Requester: Bjarne Stroustrup, Beman Dawes
Paper:

a way of manipulating files that are part of a directory structure

Process manipulation

Requester: unknown
Paper:

Process manipulation library—allows you to iterate processes running on the system and its threads, support forking, duping a process, killing etc.

Linear algebra

Requester: Bjarne Stroustrup, Tanguy Fautré
Paper:

a good linear algebra library (Matrices and vectors)

Virtual destructors for containers

Requester: David Miller
Paper:

Versions of the standard containers with virtual destructors

Move semantics

Requester: Howard Hinnant
Paper:

Move semantics, which requires core and library support

String formatting

Requester: Gary Powell
Paper:

A string formatting library. (Aka, type safe printf) John Bates suggests that one way to improve on printf would be to have explicit parameter substitution via numbering, as opposed to the implicit ordering in printf. This would be similar to Java's MessageFormat object or Microsoft's FormatMessage API and would allow better internationalization support.

Runtime generic container

Requester: Gary Powell
Paper:

A container to hold anything, like dynamic_any

Date and time

Requester: Gary Powell
Paper:

A date/time library, a date is not a duration! And an end to time_t.

Graph algorithms

Requester: Gary Powell
Paper:

a graph library, aka boost/graph (supplements std containers)

Quaternions and octonions

Requester: Gary Powell
Paper:

math/octonion & math/quaterion's (used by game designers for 3d math.)

Units

Requester: Gary Powell, Walter Brown
Paper:

a SI/Units library. ( e = m c², and end to the mars lander crashes.)

More STL algorithms

Requester: Matt Austern
Paper:

New STL algorithms: copy_if, is_sorted, versions of the uninitialized_* algorithms that take allocator arguments.

Web services

Requester: Jonathan Schilling
Paper:

A SOAP- and XML-based web services binding to the standard library. There would also need to be some kind of metalanguage/directives mechanism for marking within the C++ source, which classes and functions are being exposed as web services.

More special functions

Requester: Paul Bristow
Paper: N1668 = 04-0108, "A Proposal to add Mathematical Functions for Statistics to the C++ Standard Library", Paul Bristow

More math functions for statistics: Student's t function, Kolmogorov statistic, incomplete beta function, digamma function, and so on.

Full-width integer operations

Requester: Matt Austern
Paper:

A mechanism for accessing integer operations that every processor has: addition with carry, full-width multiplication, and division with remainder and quotient. The signatures might look something like this: pair<UInt, bool> add(UInt, UInt);, pair<UInt, UInt> mult(UInt, UInt);, pair<UInt, UInt> div(UInt, UInt);. We would probably want overloads for unsigned int, unsigned long, unsigned long long (assuming it's added to the core language), and maybe unsigned char.

Database support

Requester: Rüdiger Brünner
Paper:

Generic database support; STL-based recordset operations

Serialization

Requester: Rüdiger Brünner
Paper:

Library for binary object serialization/deserialization including object factory, versioning support, support for native datatypes and Standard Library classes (std::basic_string, STL containers, std::complex, etc.)

Fixed-point arithmetic

Requester: Rüdiger Brünner
Paper:

Fixed-point arithmetic library and currency class based upon it

Patterns

Requester: Rüdiger Brünner
Paper:

Singleton template (like in the Loki library) and probably also generic implementations of other common patterns

Interval arithmetic

Requester: Sylvain Pion
Paper:

The Sun compiler provides a built-in type for interval arithmetic, and Boost and CGAL have interval classes. There are many other implementations elsewhere.

Class factory implementation

Requester: Alisdair Meredith
Paper:

One item I would like to add to the LWG wish list if a 'class factory' or 'virtual constructor' implementation, again inspired by Loki. I have been wrestling with several points of the design space, trying to find the best balance. Was hoping to propose something for TR2 but there is one issue that really needs core (i.e. Evolution) support before we can have a truly satisfying interface, and that is the ability to work with any constructor rather than just the default.

A mix of perfect forwarding and var-arg template parameters will get us some way there, but I'm still not sure it is enough.

Another issue not immediately tied in is the progress on dynamic libraries, as class factories often lie at the heart of plug-in schemes.

Beyond that it is a matter of defining the optimal interface. The Loki version is quite policy driven eg. for return type. Do we want to allow a variety of returns, or fix on tr1::shared_ptr, or auto_pr (or even move_ptr if it arrives)?

Full support for user-defined memory models

Requester: Dmitriy Morozov and others
Paper:

The standard's allocator machinery, in principle, allows users to define allocators with alternate memory models. (The original motivation was MS-DOS's "near" and "far" memory models.) Allocators have reference and pointer typedefs. However, this support is seriously limited. First, the current standard doesn't allow any freedom for Alloc::reference: it is required to be T&. Second, 20.1.5/4-5 says that standard library implementations are allowed to ignore an allocator's memory model typedefs and assume that all allocators use the usual memory model.

These restrictions should be removed. This may require some core language changes. It may also require writing out requirements that an alternate memory model must satisfy.