Doc. no. J16/01-0039=WG21/N1325
Date: 23 October 2001
Project: Programming Language C++
Reply to: Beman Dawes <bdawes@acm.org>
The purpose of this document is to stimulate discussion on several topics:
The Library Issues List has been successful both an organization tool and as memory of past actions. A Proposals List is intended to serve the same purposes for the TR. Presumably there will be an issues list maintainer, responsible for updates. Internal mechanisms and public availability would also follow the Issues List model.
Detailed proposals are usually lengthy. They may contain actual library specifications, plus introductions, rationale, history, acknowledgments, reference implementations, example programs, tutorials, and more. Material may change frequently, particularly early in the life of a proposal. Thus it will be much more manageable if Proposal List entries contain references to the detailed proposal material rather than the material itself.
Early in the lifetime of a proposal, it is acceptable (and even expected) that references may be to world-wide web pages under control of the submitter rather than the LWG. As a proposal progresses, references to proposed TR wording will change to be references to committee documents on some LWG controlled web site or CVS repository.
Final acceptance of a proposal for the Technical Report will require specific TR wording in a committee numbered document, and will have to be written in full standardese. Such a document is difficult to write, particularly for those not on the committee and not experienced in writing standardese.
Library developers would be discouraged from submitting proposals if the initial proposal had to be written in standardese, since the submitter would not yet know if the proposal stood even a chance of acceptance. To avoid this problem, the LWG does not require initial proposals be written in standardese. Final acceptance, however, always requires full TR wording in standardese.
New - The proposal has not yet been reviewed by the LWG. The proposal should not be construed as the view of LWG.
Open - The LWG has discussed the proposal but is not yet ready to move the proposal forward. There are several possible reasons for open status: for example, the LWG may wish to study the proposal further, is awaiting additional material from the submitter, has requested modifications to the proposal, or is awaiting final TR wording. Italicized notes by the list maintainer serve to remind the LWG of the details of the current status.
Dup - The LWG has reached consensus that the proposal is a duplicate of another proposal, and will not be further dealt with. A Rationale identities the duplicated proposal number.
Rejected - The LWG has reached consensus that the proposal should not be accepted for the TR. A Rationale discusses the LWG's reasoning.
Review - Exact wording for the TR is now available for review.
Ready - The LWG has reached consensus that the proposal is ready to forward to the full committee for inclusion in the TR.
TR - The full committee has accepted the proposal for inclusion in the Technical Report.
Pure - The proposal is not expected to break source or binary compatibility for existing uses or implementations of the standard library.
Impure - The proposal is expected to break source or binary compatibility for existing uses or implementations of the standard library.
If there is some doubt, a proposal should be classified as impure.
Std C++ - Both the interface and a reasonable implementation require only standard C++ as defined in ISO/IEC 14882:1998.
Core change - Either the interface or reasonable implementations require a core language change.
Compiler - The interface is standard C++, but no reasonable implementation is possible without compiler support. For example, a function template which determines if a structure is a POD requires compiler support but not a core language change.
Native - The interface is standard C++, but implementations will normally use platform dependent native libraries. Thus such a proposal may not be implementable on all hosted C++ platforms.
For proposals representing substantial existing practice, list suppliers (in abbreviated form). For widely available extensions like hash tables, specify "Many".
None - Indicates there is no widely available existing practice.
Yes - There is a working reference implementation available. [What does "available" mean? Does it include "available for a million dollar fee", "if you sign an obnoxious NDA", or "if you aren't a competitor"? I'd say "no" to all of those. On the other hand, I certainly would expect the reference implementation to be copyrighted and not necessarily freely available for all uses. Perhaps "available for inspection by LWG members?"]
No - Doesn't meet the above criteria.
One or more references to the documentation and reference implementation, preferable in the form of URLs. URLs should be spelled out in full so that they are readable on printed copies of this Proposals List.
Section: 18.7 Status: New Submitter:
Boost Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Many Implementation: Yes
Reference: ISO/IEC 9899:1999 Programming Language C, www.boost.org/libs/integer/cstdint.htm
The 1999 revision of the C Programming Language added several new library facilities. The C99 <stdint.h> header is proposed for inclusion by reference in the C++ Standard Library as <cstdint>. It provides typedef's for writing portable code with specific integer width requirements. A C++ implementation has been available for several years from Boost.
The proposal falls into the Standards Coordination and Infrastructure categories identified in 01-0028==N1314 as targets for the TR.
Section: 18 Status: New Submitter:
John Maddock Date: 4 Oct 2001
Type: Pure Requires: Compiler
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/type_traits/index.htm
The proposal supplies template classes that describe the fundamental properties of a type; each class represents a single type property or a single type transformation.
Some of the type categorizations require compiler support.
The Boost Type Traits Library is well-know and widely used. See www.boost.org/libs/type_traits/c++_type_traits.htm for an article appearing in Dr. Dobb's Journal. Once type traits become available, a significant percentage (10-20%) of template-base libraries use them directly, while up to one-third use type traits indirectly (based on a Boost library dependency analysis.)
Type traits falls into the Infrastructure category identified in 01-0028==N1314 as a target for the TR. Type traits allows easy detection of certain type errors (is a template class parameter a POD as required?) that are otherwise difficult or impossible to detect.
Acknowledgements: Type traits is based on contributions by Steve Cleary, Beman Dawes, Aleksey Gurtovoy, Howard Hinnant, Jesse Jones, Mat Marcus, John Maddock and Jeremy Siek
Section: 21 Status: New Submitter:
John Maddock Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/regex/index.htm
This proposal provides full regular expression facilities, including wchar_t support. Wherever possible, compatibility has been maintained with other libraries, particularly the Henry Spencer, Perl, GNU, and POSIX regular expression libraries. The proposal contains POSIX compatibility and other subsidiary functions which the LWG may wish to exclude.
An easy-to-read introduction appeared in Dr. Dobb's Journal, see www.ddj.com/articles/2001/0110/0110a/0110a.htm
A possible criticism is that more convenience functions interoperating with std::basic_string are needed. Darin Adler at Boost is working on a set of string algorithms which include overloads for regular expressions. This approach uniformly supplies useful functionality, regardless of whether arguments are plain strings or regular expressions.
Regular expressions are important both in theory and practice. They fall into one of the domains (text processing) identified in 01-0028==N1314 as a target for the TR. The regex++ library is well known, and was in use before being accepted as a Boost library. Based on both user feedback and site page view statistics, regex++ is among the most heavily used Boost libraries.
Section: 20 Status: New Submitter:
Greg Colvin, Beman Dawes Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/smart_ptr/index.htm
The proposal supplies four smart pointer class templates (which interoperate with auto_ptr when appropriate):
scoped_ptr |
Simple sole ownership of single objects. Noncopyable. |
| scoped_array | Simple sole ownership of arrays. Noncopyable. |
| shared_ptr | Object ownership shared among multiple pointers |
| shared_array | Array ownership shared among multiple pointers. |
Several common questions are answered by www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ
These smart pointers fill major gaps and remove major embarrassments in the current standard:
Based on both user feedback and site page view statistics, these smart pointers are among the most heavily used Boost libraries. They (particularly shared_ptr) have been recommended in books, magazine articles, and newsgroup postings by both C++ experts and everyday users. The proposal falls in the filling gaps category identified in 01-0028==N1314 as a target for the TR.
Section: 26 Status: New Submitter:
Jens Maurer Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/random/index.html
This proposal provides a framework for random number generators and distributions. Both the RNG's and distributions have well-defined properties for use in demanding numerics and security domains, as well as in everyday programming. Adaptors to meet RandomNumberGenerator requirements (25.2.11 [lib.alg.random.shuffle]) and input iterator requirements (24.1.1 [lib.input.iterators]) are also provided.
The proposal includes over a dozen generators in six different families, and includes about a dozen distributions.
The proposal falls into one of the domains (numerics) identified in 01-0028==N1314 as a target for the TR. It provides alternatives to rand(), which is not usable in many applications because of undefined generation and distribution properties, or because of unreliable multi-threaded operation (due to possible corruption of rand()'s internal state.)
Section: 26 Status: New Submitter:
Paul Moore Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/rational/index.html
This proposal includes class template rational, and related support such as exception class bad_rational, and function template rational_cast.
The current specification assumes the availability of the boost/operators.hpp header (see Proposal ?). If that header doesn't become part of the TR, additional operations will have to be specified for the class rational interface.
Rational numbers are important both in theory and practice. Questions and bug reports indicate that the class sees actual use. It falls into one of the domains (numerics) identified in 01-0028==N1314 as a target for the TR.
Section: ? Status: New Submitter:
William Kempf Date: 4 Oct 2001
Type: Pure Requires: Native
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/thread/doc/index.html
This proposal provides basic multithreading functionality, in a form designed specifically for the C++ Standard Library.
The very public development process, with over one hundred people contributing comments and insights, ensured that a wide-range of concerns were exposed, and resulted in a much stronger library. The documentation includes a great deal of rationale for important design decisions.
The proposal is suitable for a wide range of hosted C++ environments, but is intended to be an optional component of the C++ Standard Library since implementors may not wish to support platforms where concurrent programming support is limited, non-existent, or unimportant. The proposal has been implemented on UNIX using POSIX threads, and Windows using both the native Win32 threads and POSIX threads.
The proposal falls in the filling gaps and systems programming domain categories identified in 01-0028==N1314 as targets for the TR.
Revised October 23, 2001
--- End ---