<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Library TR Proposals List Trial Balloon</title>
</head>

<body bgcolor="#FFFFFF" text="#000000">

<p>Doc. no.&nbsp;&nbsp; J16/01-0039=WG21/N1325<br>
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 23 October 2001<br>
Project:&nbsp;&nbsp;&nbsp;&nbsp; Programming Language C++<br>
Reply to:&nbsp;&nbsp; Beman Dawes &lt;<a href="mailto:bdawes@acm.org">bdawes@acm.org</a>&gt;</p>

<h1>Library Technical Report Proposals List Trial Balloon</h1>

<h2>Introduction</h2>

<p>The purpose of this document is to stimulate discussion on several topics: 

<ul>
  <li>A Proposals List for tracking the status of TR proposals, similar to the Issues List.</li>
  <li>Proposals List entries contain references to proposal documentation, not the lengthy
    technical wording itself.</li>
  <li>Proposal Status; the states a proposal must go through to reach final acceptance.</li>
  <li>Other details of Proposal List contents.</li>
  <li>Initial feedback on several actual proposals.</li>
</ul>

<h2>Proposals List </h2>

<p>The Library Issues List has been successful both an organization tool and as memory of
past actions.&nbsp;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. </p>

<h2>Entries contain references </h2>

<p>Detailed proposals are usually lengthy.&nbsp; They may contain actual library
specifications, plus introductions, rationale, history, acknowledgments, reference
implementations, example programs, tutorials, and more.&nbsp; Material may change
frequently, particularly early in the life of a proposal.&nbsp; Thus it will be much more
manageable if Proposal List entries contain references to the detailed proposal material
rather than the material itself. </p>

<p>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.&nbsp; 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. </p>

<h2>Standardese</h2>

<p>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. </p>

<p>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&nbsp; if
the proposal stood even a chance of acceptance.&nbsp; To avoid this problem, the LWG does
not require initial proposals be written in standardese.&nbsp; Final acceptance, however,
always requires full TR wording in standardese. </p>

<h2><a name="Status"><b>Proposal Status</b></a></h2>

<p><b><a name="New">New</a></b> - The proposal has not yet been reviewed by the LWG. The
proposal should not be construed as the view of LWG.</p>

<p><a name="Open"><b>Open</b></a> - 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.&nbsp; Italicized notes by the list maintainer serve to remind the LWG of
the details of the current status.&nbsp;</p>

<p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that the proposal is a
duplicate of another proposal, and will not be further dealt with. A <b>Rationale</b>
identities the duplicated proposal number.</p>

<p><a name="Rejected"><b>Rejected</b></a> - The LWG has reached consensus that the
proposal should not be accepted for the TR. A <b>Rationale</b> discusses the LWG's
reasoning.</p>

<p><a name="Review"><b>Review</b></a> - Exact wording for the TR is now available for
review.</p>

<p><a name="Ready"><b>Ready</b></a> - The LWG has reached consensus that the proposal is
ready to forward to the full committee for inclusion in the TR.</p>

<p><b><a name="TR">TR</a></b> - The full committee has accepted the proposal for inclusion
in the Technical Report.</p>

<h2>Type</h2>

<p><b><a name="Pure">Pure</a></b> - The proposal is not expected to break source or binary
compatibility for existing uses or implementations of the standard library.</p>

<p><b><a name="Impure">Impure</a></b> - The proposal is expected to break source or binary
compatibility for existing uses or implementations of the standard library.</p>

<p>If there is some doubt, a proposal should be classified as impure.</p>

<h2>Requires</h2>

<p><b><a name="Std">Std</a> C++</b> - Both the interface and a reasonable implementation
require only standard C++ as defined in ISO/IEC 14882:1998.</p>

<p><b><a name="Core">Core</a> change</b> - Either the interface or reasonable
implementations require a core language change.</p>

<p><b><a name="Compiler">Compiler</a></b> - 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.</p>

<p><a name="Native"><b>Native</b></a> - 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.</p>

<h2>Existing-practice</h2>

<p>For proposals representing substantial existing practice, list suppliers (in
abbreviated form). For widely available extensions like hash tables, specify
&quot;Many&quot;.</p>

<p><b>None</b> - Indicates there is no widely available existing practice.</p>

<h2>Implementation</h2>

<p><b><a name="Yes">Yes</a></b> - There is a working reference implementation available. <i>[What
does &quot;available&quot; mean?&nbsp; Does it include &quot;available for a million
dollar fee&quot;, &quot;if you sign an obnoxious NDA&quot;, or &quot;if you aren't a
competitor&quot;? I'd say &quot;no&quot; to all of those.&nbsp; On the other hand, I
certainly would expect the reference implementation to be copyrighted and not necessarily
freely available for all uses.&nbsp; Perhaps &quot;available for inspection by LWG
members?&quot;]</i></p>

<p><b><a name="No">No</a></b> - Doesn't meet the above criteria.</p>

<h2>Reference</h2>

<p>One or more references to the documentation and reference implementation, preferable in
the form of URLs.&nbsp; URLs should be spelled out in full so that they are readable on
printed copies of this Proposals List.</p>

<hr>

<h2>Proposals</h2>

<hr>

<h3>1. Header &lt;cstdint&gt;</h3>

<p><b>Section:</b> 18.7&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b>
Boost&nbsp; <b>Date:</b> 4 Oct 2001<br>
<b>Type:</b> <a href="#Pure">Pure</a>&nbsp; <b>Requires:</b> <a href="#Std">Std C++</a>&nbsp;
<b>Existing-practice:</b> Many&nbsp; <b>Implementation:</b> <a href="#Yes">Yes<br>
</a><b>Reference:</b> ISO/IEC 9899:1999 Programming Language C, <a
href="http://www.boost.org/libs/integer/cstdint.htm">www.boost.org/libs/integer/cstdint.htm</a></p>

<p>The 1999 revision of the C Programming Language added several new library
facilities.&nbsp; The C99 <i>&lt;stdint.h&gt;</i> header is proposed for inclusion by
reference in the C++ Standard Library as <i>&lt;cstdint&gt;</i>.&nbsp; It provides
typedef's for writing portable code with specific integer width requirements. A C++
implementation has been available for several years from Boost.</p>

<p>The proposal falls into the <i>Standards Coordination</i> and <i>Infrastructure</i>
categories identified in 01-0028==N1314 as targets for the TR.</p>

<hr>

<h3>2. Type Traits</h3>

<p><b>Section:</b> 18&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b>
John Maddock&nbsp; <b>Date:</b> 4 Oct 2001<br>
<b>Type:</b> <a href="#Pure">Pure</a>&nbsp; <b>Requires:</b> <a href="#Compiler">Compiler</a>&nbsp;
<b>Existing-practice:</b> Boost&nbsp; <b>Implementation:</b> <a href="#Yes">Yes<br>
</a><b>Reference:</b> <a href="http://www.boost.org/libs/type_traits/index.htm">www.boost.org/libs/type_traits/index.htm</a></p>

<p>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.</p>

<p>Some of the type categorizations require compiler support.</p>

<p>The Boost Type Traits Library is well-know and widely used.&nbsp; See <a
href="http://www.boost.org/libs/type_traits/c++_type_traits.htm">www.boost.org/libs/type_traits/c++_type_traits.htm</a>
for an article appearing in Dr. Dobb's Journal.&nbsp; 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.)&nbsp;&nbsp; </p>

<p>Type traits falls into the <i>Infrastructure</i> 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.</p>

<p><b>Acknowledgements:</b> Type traits is based on contributions by Steve Cleary, Beman
Dawes, Aleksey Gurtovoy, Howard Hinnant, Jesse Jones, Mat Marcus, John Maddock and Jeremy
Siek</p>

<hr>

<h3>3. Regular Expressions</h3>

<p><b>Section:</b> 21&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b>
John Maddock&nbsp; <b>Date:</b> 4 Oct 2001<br>
<b>Type:</b> <a href="#Pure">Pure</a>&nbsp; <b>Requires:</b> <a href="#Std">Std C++</a>&nbsp;
<b>Existing-practice:</b> Boost&nbsp; <b>Implementation:</b> <a href="#Yes">Yes<br>
</a><b>Reference:</b> <a href="http://www.boost.org/libs/regex/index.htm">www.boost.org/libs/regex/index.htm</a></p>

<p>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.</p>

<p>An easy-to-read introduction appeared in Dr. Dobb's Journal, see <a
href="http://www.ddj.com/articles/2001/0110/0110a/0110a.htm">www.ddj.com/articles/2001/0110/0110a/0110a.htm</a></p>

<p>A possible criticism is that more convenience functions interoperating with
std::basic_string are needed.&nbsp; 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.</p>

<p>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.</p>

<hr>

<h3>4. Smart Pointers</h3>

<p><b>Section:</b> 20&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b>
Greg Colvin, Beman Dawes&nbsp; <b>Date:</b> 4 Oct 2001<br>
<b>Type:</b> <a href="#Pure">Pure</a>&nbsp; <b>Requires:</b> <a href="#Std">Std C++</a>&nbsp;
<b>Existing-practice:</b> Boost&nbsp; <b>Implementation:</b> <a href="#Yes">Yes<br>
</a><b>Reference:</b> <a href="http://www.boost.org/libs/smart_ptr/index.htm">www.boost.org/libs/smart_ptr/index.htm</a></p>

<p>The proposal supplies four smart pointer class templates (which interoperate with <b>auto_ptr</b>
when appropriate):</p>
<div align="left">

<table border="1" cellPadding="4" cellSpacing="0">
<tbody>
  <tr>
    <td><p align="left"><strong>scoped_ptr</strong></td>
    <td>Simple sole ownership of single objects. Noncopyable.</td>
  </tr>
  <tr>
    <td><strong>scoped_array</strong></td>
    <td>Simple sole ownership of arrays. Noncopyable.</td>
  </tr>
  <tr>
    <td><strong>shared_ptr</strong></td>
    <td>Object ownership shared among multiple pointers</td>
  </tr>
  <tr>
    <td><strong>shared_array</strong></td>
    <td>Array ownership shared among multiple pointers.</td>
  </tr>
</tbody>
</table>
</div>

<p>Several common questions are answered by <a
href="http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ">www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ</a></p>

<p>These smart pointers fill major gaps and remove major embarrassments in the current
standard: 

<ul>
  <li><b>shared_ptr</b> and <b>shared_array</b> work well with C++ Standard Library
    containers, which is a commonly requested need of container users. (The need is often
    expressed as the question &quot;Why do I get compile errors when I try to put an <b>auto_ptr</b>
    in a container?&quot;)</li>
  <li><b>scoped_ptr</b> and <b>scoped_array</b> provide &quot;resource acquisition is
    initialization&quot; support for non-transferable, non-shared, objects.</li>
  <li><b>scoped_array</b> and <b>shared_array</b> are requested by users who do not want the
    fuller feature set of <b>vector</b>, particularly reallocation and the memory overhead it
    implies. Experienced users view a &quot;use vector&quot; response as pedantic and
    condescending.</li>
</ul>

<p>Based on both user feedback and site page view statistics, these smart pointers are
among the most heavily used Boost libraries. They (particularly <b>shared_ptr</b>) have
been recommended in books, magazine articles, and newsgroup postings by both C++ experts
and everyday users. The proposal falls in the <i>filling gaps</i> category identified in
01-0028==N1314 as a target for the TR.</p>

<hr>

<h3>5. Random Numbers</h3>

<p><b>Section:</b> 26&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b>
Jens Maurer&nbsp; <b>Date:</b> 4 Oct 2001<br>
<b>Type:</b> <a href="#Pure">Pure</a>&nbsp; <b>Requires:</b> <a href="#Std">Std C++</a>&nbsp;
<b>Existing-practice:</b> Boost&nbsp; <b>Implementation:</b> <a href="#Yes">Yes<br>
</a><b>Reference:</b> <a href="http://www.boost.org/libs/random/index.html">www.boost.org/libs/random/index.html</a></p>

<p>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.</p>

<p>The proposal includes over a dozen generators in six different families, and includes
about a dozen distributions.</p>

<p>The proposal falls into one of the domains (numerics) identified in 01-0028==N1314 as a
target for the TR. It provides alternatives to <i>rand()</i>, which is not usable in many
applications because of undefined generation and distribution properties, or because
of&nbsp; unreliable multi-threaded operation (due to possible corruption of <i>rand()</i>'s
internal state.)&nbsp;</p>

<hr>

<h3>6. Rational Numbers</h3>

<p><b>Section:</b> 26&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b>
Paul Moore&nbsp; <b>Date:</b> 4 Oct 2001<br>
<b>Type:</b> <a href="#Pure">Pure</a>&nbsp; <b>Requires:</b> <a href="#Std">Std C++</a>&nbsp;
<b>Existing-practice:</b> Boost&nbsp; <b>Implementation:</b> <a href="#Yes">Yes<br>
</a><b>Reference:</b> <a href="http://www.boost.org/libs/rational/index.html">www.boost.org/libs/rational/index.html</a></p>

<p>This proposal includes class template <i>rational</i>, and related support such as
exception class <i>bad_rational</i>, and function template <i>rational_cast</i>.</p>

<p>The current specification assumes the availability of the boost/operators.hpp header
(see Proposal ?).&nbsp; If that header doesn't become part of the TR, additional
operations will have to be specified for the class <i>rational</i> interface.</p>

<p>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.</p>

<hr>

<h3>7. Threads</h3>

<p><b>Section:</b> ?&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b>
William Kempf&nbsp; <b>Date:</b> 4 Oct 2001<br>
<b>Type:</b> <a href="#Pure">Pure</a>&nbsp; <b>Requires:</b> <a href="#Native">Native</a>&nbsp;
<b>Existing-practice:</b> Boost&nbsp; <b>Implementation:</b> <a href="#Yes">Yes<br>
</a><b>Reference:</b> <a href="http://www.boost.org/libs/thread/doc/index.html">www.boost.org/libs/thread/doc/index.html</a></p>

<p>This proposal provides basic multithreading functionality, in a form designed
specifically for the C++ Standard Library.</p>

<p>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.&nbsp; The documentation includes a great deal of rationale for important
design decisions.&nbsp;</p>

<p>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.&nbsp; The proposal has been implemented on UNIX using POSIX threads, and
Windows using both the native Win32 threads and POSIX threads.</p>

<p>The proposal falls in the <i>filling gaps</i> and <i>systems programming domain</i>
categories identified in 01-0028==N1314 as targets for the TR.</p>

<hr>

<p>Revised <!--webbot bot="Timestamp" startspan S-Type="EDITED" S-Format="%B %d, %Y" -->October 23, 2001<!--webbot
bot="Timestamp" i-checksum="30085" endspan --> </p>

<p>--- End ---</p>
</body>
</html>
