<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 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Library TR Proposals and Issues List</title>
</head>

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

<p>Doc. no.&nbsp;&nbsp; J16/02-0055=WG21/N1397<br>
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 30 October 2002<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 and Issues List (Revision 4)</h1>

<h2>Introduction</h2>

<p>The Library Technical Report (TR) Proposals and Issues List serves as memory 
of actions past and actions needed.&nbsp; It is modeled on the highly successful 
Library and Core issues lists.</p>

<p>The Library Working Group (LWG) is responsible for evaluating most proposals. 
Proposals identified by the LWG or Evolution Working Group (EWG) chairs as 
raising language related issues will be evaluated first by the EWG.&nbsp; Working 
group schedules will be set so that LWG members can participate in EWG 
discussions of these proposals.</p>

<h2>Entries contain references </h2>

<p>TR Proposals and Issues List entries often contain references to detailed proposals rather than 
the proposals themselves. Detailed proposals are usually lengthy.&nbsp; They may 
contain actual library specifications, plus introductions, rationale, history, 
acknowledgments, reference implementations, example programs, tutorials, and 
more.</p>

<p>Early in the lifetime of a proposal, it is acceptable that references may be 
to world-wide web pages under control of the submitter rather than the LWG.&nbsp; 
As a proposal progresses, it will take the form of a regular numbered committee 
document.</p>

<h2>Standardese</h2>

<p>Final acceptance of a proposal requires specific TR
wording in full 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 preliminary proposals be written in standardese.&nbsp; Actual 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 or issue 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>
identifies 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>T<a name="TR">R</a></b> - The full committee has accepted the proposal for inclusion
in the Library 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="Extension">Extension</a></b> - Either the interface or reasonable
implementations require a core language change or extension.</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>

<h2>Formal Proposal</h2>

<p>One or more references to the actual numbered committee document which 
contains the formal proposal in full standardese, 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>

<p>Left blank if a formal proposal has not yet been received.</p>

<p>Most formal proposals go through several revisions.&nbsp; The document number 
for each revision should be listed, with the most recent first.</p>

<hr>

<h2>Proposals and Issues</h2>

<hr>

<h3>1. C99 Library Additions to C++</h3>

<p><b>Section:</b> 18.7&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b> 
P.J. Plauger&nbsp; <b>Date:</b> 3 Feb 2002<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>
<a href="http://www.dinkumware.com/refxc.html">www.dinkumware.com/refxc.html</a>, 
ISO/IEC 9899:1999 Programming Language C<br>
<b>Formal Proposal: </b>Revised:
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1372.txt">std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1372.txt</a>, 
Original:
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt</a>, </p>

<p>The revised C standard ISO 9899:1999 (a.k.a. C99) makes extensive additions 
to the Standard C library. The most obvious ones live in six new headers, but 
the 18 existing headers (15 from C89 and 3 from Amendment 1) also have a host of 
additions.
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt">Document 
02-0012/N1354</a> summarizes what has been added since the C++ 
Standard froze (ISO 14882:1998), along with some suggestions for appropriate C++ 
machinery to accompany the new stuff. For a more complete description, see the 
Dinkum C99 Library Reference at <a href="http://www.dinkumware.com/refxc.html">
www.dinkumware.com/refxc.html</a>, which closely reflects the material 
summarized in the proposal. Note that Dinkumware has been shipping a combined 
C99/C++ library for the past year, so all of the proposed C++ additions have 
been implemented.</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>

<p><i>[Redmond:&nbsp; After an initial  Boost proposal query covering a 
portion of the C99 additions, PJP said that he wished to make a comprehensive 
proposal based on his experience implementing the C99 additions for Dinkumware.]</i></p>

<p><i>[Pre-Curaao: PJP submitted his comprehensive 
proposal, and Dawes withdrew the Boost proposal.]</i></p>

<p><i>[Curaao: The EWG and LWG jointly discussed 
the proposal. The decision was to proceed on separate but parallel LWG and EWG 
tracks, and thus request that PJP break the document into separate Library TR 
C99 and Evolution C99 proposals.</i></p>
<p><i>The TR proposal should cover components which 
can be implemented today using only standard C++, without any compiler support 
or language extensions. Although the LWG will look at each component in detail, 
there is general support for adding C99 library additions to the TR. While it 
may be a bit premature to supply standardese for the entire proposal, it might 
be useful to begin work, such as deciding which portions can be specified by 
reference to C99, and which will require full standardese.</i></p>
<p><i>The Evolution proposal should cover 
components which require compiler or language support (such as long long), and 
need not contain more detail than the current document; the need is for a 
checklist with recommendations rather than a detailed proposal. </i></p>
<p><i>Although those present indicated much 
interest in the library additions described, there was concern about how some 
(particularly math functions) would work within the spirit of C++.&nbsp; PJP will be 
asked to present a technical session in Santa Cruz to increase the committee's 
knowledge of C99 compatibility issues in general, but with primary focus on math 
related headers.]</i></p>

<p><i>[pre-Santa Cruz: Per the request of the EWG and LWG, the proposal was 
revised and included in the post-Curaao mailing.]</i></p>

<p><i>[Santa Cruz: The key aspects of the revised proposal were presented at an 
evening technical session. PJP and Matt Austern will work toward a formal 
proposal for the Oxford meeting.]</i></p>

<hr>

<h3>2. Type Traits</h3>

<p><b>Section:</b> 18&nbsp; <b>Status:</b> <a href="#Open">Open</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><br>
<b>Formal Proposal: </b>
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1345.html">std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1345.html</a></p>

<p>The <a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1345.htm">proposal 
(02-0003/N1345)</a> 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-known 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;Several other libraries (Loki, for example) have also 
invented type traits mechanisms. </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 initial contributions by Steve Cleary, Beman
Dawes, Aleksey Gurtovoy, Howard Hinnant, Jesse Jones, Mat Marcus, John Maddock and Jeremy
Siek.&nbsp;Later contributions have come from many others. John Maddock is the 
chief architect and library maintainer.</p>

<p><i>[Redmond: The LWG expressed great interest in the proposal query.&nbsp; In 
response to a query about Loki TypeTraits, Andrei Alexandrescu said he supports 
the Boost proposal.]</i></p>

<p><i>[Pre-Curaao: John Maddock submitted his 
formal proposal.]</i></p>

<p><i>[Curaao: The EWG and LWG jointly discussed 
the proposal. They decision was to proceed on separate but parallel LWG and EWG 
tracks, and thus request that John break the document into separate Library TR 
and Evolution proposals.</i></p>
<p><i>The updated TR proposal should cover the 
library aspects of Type Traits without mentioning how the library might be 
implemented. The LWG will proceed on the basis of this updated proposal. The 
plan is to go into the Santa Cruz meeting with a proposal which can be accepted 
for the TR, modulo minor fixes.</i></p>
<p><i>The Evolution proposal should cover 
components which require compiler or language support, or would benefit greatly 
from, and need not contain much more than the &quot;Compiler Support&quot; section of the 
current proposal.]</i></p>

<p><i>[Santa Cruz: An LWG sub-group reviewed the current (N1345.htm) formal proposal. They support the proposal in general, and have forwarded specific 
issues to John to be addressed in a revised proposal. At least two compiler 
writers reported initial implementations of the portions of the proposal where 
compiler support is useful.]</i></p>

<hr>

<h3>3. Regular Expressions</h3>

<p><b>Section:</b> 21&nbsp; <b>Status:</b> <a href="#Open">Open</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><br>
<b>Formal Proposal:</b>
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1386.htm">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1386.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>

<p><i>[Curaao: A brief discussion resulted in these action items:</i></p>

<ul>
  <li><i>John should query the LWG via the lib reflector with his matching rules 
  questions.</i></li>
  <li><i>John should proceed with his formal proposal.</i></li>
  <li><i>Jeremy will query John with Nathan's question about supplying both 
  &quot;push&quot; and &quot;pull&quot; interfaces.]</i></li>
</ul>

<p><i>[Pre-Santa Cruz: The formal proposal is available in the pre-Santa Cruz 
mailing. It reflects push/pull and other interface changes to better conform to 
C++ Standard Library practice.&nbsp; It reflects extensive discussions with 
interested parties both privately and on the library reflector. Eric Niebler, 
the author of GRETA, supports the proposal although he continues to try to 
convince John that templating basic_regex on iterator type rather than character 
type would be beneficial. The proposal includes proposed TR wording. ]</i></p>

<p><i>[Santa Cruz: An LWG sub-group reviewed the formal 
proposal. They support the proposal, and have forwarded specific 
issues to John to be addressed in a revised proposal. Particular issues include 
lack of international support for ECMAScript.]</i></p>

<hr>

<h3>4. Shared_ptr</h3>

<p><b>Section:</b> 20&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b> 
Peter Dimov, Darin Adler,
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/shared_ptr.htm">
www.boost.org/libs/smart_ptr/shared_ptr.htm</a><br>
<b>Formal Proposal: </b></p>

<p>Because the wide usefulness in managing memory, Boost supplies a whole family 
of smart pointers. Many other smart pointers with a wide range of features and 
designs are available from other sources. Among all the choices, <b>
boost::shared_ptr</b> stands out as best meeting the requirements for a Standard 
Library smart pointer.</p>
<p>The rationale for inclusion of <b>shared_ptr</b> in the Standard Library is 
very strong. It provides a Standard Library smart pointer which: </p>
<ul>
  <li>Can uniformly be recommended to programmers from novices to experts for a 
  very wide range of uses.</li>
  <li>Can be used in Standard Library containers, filling a major gap in the 
  current Standard Library. </li>
  <li>Standardizes flexible smart pointer communication between libraries, 
  including third-party libraries. </li>
  <li>Reflects existing practice over a decade of refinement and use, including 
  many non-obvious enhancements. </li>
  <li>Is widely recommended in books, magazine articles, and newsgroup postings 
  by both C++ experts and everyday users. </li>
  <li>Has been reinvented thousands of times (often with gratuitous mistakes and 
  misfeatures).</li>
  <li>Is very hard to implement correctly, particularly as regards exception and 
  thread safety. </li>
  <li>Allows several implementation techniques, leaving implementors room for 
  tradeoffs.</li>
</ul>

<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><i>[Curaao: The LWG expressed serious concerns 
about the proposal, and about other smart pointer issues:</i></p>

<ul>
  <li><i>Because user needs are so varied, Standard 
  Library smart pointers should support a full feature model, including user 
  supplied behavior. A policy-based design is seen as the only candidate likely 
  to meet this criteria. [[Please study the <b>shared_ptr</b> two-argument 
  constructor that allows a custom deleter. This relatively recent backwards 
  compatible-addition supports a fuller feature model than prior versions. Also 
  remember that concern over feature models can mask the fact that some features 
  are much more useful than others.&nbsp; One of the reasons <b>shared_ptr</b> 
  has been so successful is that in the great majority of cases it supplies all 
  the features that users need.]]<br>
&nbsp;</i></li>
  <li><i>Because of the need for a single smart 
  pointer to recommend for everyday use, and for interoperability between 
  third-party libraries, <b>shared_ptr</b> is seen as a likely candidate for 
  standardization. The LWG is interested primarily in the interface and with 
  interoperability, although aware that implementation might well be forwarded 
  to a policy-based smart pointer. [[The proposal has been simplified to include 
  only <b>shared_ptr</b>, and perhaps <b>weak_ptr</b>.]]<br>
&nbsp;</i></li>
  <li><i>Standard Library smart pointers should be 
  viewed as a whole to ensure consistency and interoperability; thus the idea of 
  unrelated proposals for non-policy based and policy-based smart pointers meets 
  much resistance. [[Agreed.]]<br>
&nbsp;</i></li>
  <li><i>Proliferation of Standard Library smart 
  pointers is a serious concern; if a policy-based smart pointer and a 
  compatible shared_ptr were available, they would be preferred; <b>scoped_ptr</b>,
  <b>scoped_array</b>, and <b>shared_array</b> were not viewed favorably by many 
  LWG members. [[<b>scoped_ptr</b>,
  <b>scoped_array</b>, and <b>shared_array</b> have been removed from the 
  proposal.]]<br>
&nbsp;</i></li>
  <li><i>LWG members are very concerned that &quot;you 
  don't have to pay for what you don't use.&quot; This is particularly true of 
  memory; increased memory use due to multiple inheritance or to accommodate <b>weak_ptr</b>, for example, is viewed as a serious problem. 
  [[Issues related to <b>weak_ptr</b> are a side issue that can be resolved 
  after the basic proposal is accepted. Also, be aware that different 
  implementation techniques are possible, and they may make various speed vs 
  space tradeoffs. These choices are not mandated by the proposal.]]<br>
&nbsp;</i></li>
  <li><i>LWG members are concerned about usability 
  and flexibility of designs with multiple template policy parameters.&nbsp; A 
  single policy parameter, with policy composition by chained inheritance, would 
  seem to have usability, flexibility, and inter-policy communication 
  advantages. [[While this is a serious concern with some smart pointers, it is 
  of no concern for <b>shared_ptr</b> because it does not use any template 
  policy parameters.]]<br>
&nbsp;</i></li>
  <li><i>In a quick (no discussion of exact meaning 
  of terms) straw poll, the vote was 9 1/2 yes, 0 no, to the question of whether 
  or not a policy-based smart pointer should support arrays.&nbsp; (The 1/2 vote 
  was from someone undecided.) [[Modern versions of <b>shared_ptr</b> allow many 
  forms of memory management via a custom deleter, although use with arrays is 
  rarely a good idea because derived to base conversions don't make sense for an 
  array.]]<br>
&nbsp;</i></li>
  <li><i>There was a bit of discussion and show of 
  hands on non-member versus member functions.&nbsp; No clear guidance resulted; 
  the existing use of member functions in std::auto_ptr and the Boost smart 
  pointers muddied the question. [[The <b>shared_ptr</b> developers would 
  consider changing some functions to non-member if the LWG desired.]]</i></li>
</ul>

<p><i>Note that the LWG is still considers many of 
these concerns as subject to change, as proposals are refined.]</i></p>

<p><i>[pre-Santa Cruz: The proposal has been modified to reflect some of the LWG 
concerns from Curaao. Responses to specific concerns are given in [[...]] 
above.</i></p>

<p><i>The submitters plan a 
formal proposal for the Oxford meeting.]</i></p>

<hr>

<h3>5. Random Numbers</h3>

<p><b>Section:</b> 26&nbsp; <b>Status:</b> <a href="#Open">Open</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><br>
<b>Formal Proposal: </b></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.)</p>

<p><i>[Curaao: Jens led a brief discussion resulting in these action items:</i></p>

<ul>
  <li><i>Jens will work on a formal proposal</i></li>
  <li><i>Beman will query Andy about how to describe generator semantics in 
  standardese.</i></li>
</ul>

<p><i>Walter Brown reported that users in the numerics community would like more 
rather than less generators included, so the question of how to describe in 
standardese is important.]</i></p>

<p><i>[Pre-Santa Cruz: Jens has written a formal proposal (02-0056/N1398) which 
will be in the post-meeting mailing. It 
reflects improvements based on feedback from domain experts. It also has 
rationalized the selection of particular generators and distributions for 
standardization. It includes TR proposed wording. Jens will spend part of the week before the Santa Cruz 
meeting at Fermilab, consulting with library users.</i></p>

<p><i>Santa Cruz: Jens discussed issues with various LWG members, and is making 
modifications based on both user and LWG feedback.] </i></p>

<hr>

<h3>6. Rational Numbers</h3>

<p><b>Section:</b> 26&nbsp; <b>Status:</b> <a href="#Open">Open</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><br>
<b>Formal Proposal: </b></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>

<p><i>[Redmond: Some LWG members thought rational numbers were close to the 
boundary between what should and shouldn't be part of the standard library.&nbsp; 
They would like to see a few more clear cut cases.]</i></p>

<p><i>[Pre-Curaao: Paul comments on rationale for inclusion; from a 
mathematical point of view, having complex numbers, but not rationals, seems 
odd. From a practical computing position, I have never needed complex numbers, 
but have occasionally wanted rationals.</i></p>

<p><i>Paul also comments that without an unlimited-precision integer type on 
which to base the rational class, the usefulness of rational&lt;&gt; is drastically 
diminished. Both double and rational&lt;int&gt; have subtle rounding, precision, and 
other issues. With double, these properties are fairly well-known, especially by 
the sort of people who are likely to hit them. With rational&lt;int&gt;, they are 
*not* well known. On the contrary, the sort of people who might use rational&lt;int&gt; 
are very likely to completely miss the fact that there are such problems.</i></p>

<p><i>It's arguable that these sort of issues make rational&lt;&gt; inappropriate for 
the standard library. And it's *definitely* arguable that unlimited-precision 
integers are more appropriate, and should be considered first. On the other 
hand,&nbsp; there is no significant real-world experience to indicate how likely 
the issues with using limited-precision integers would be to cause problems in 
practice. This makes assessing the risks difficult.]</i></p>

<p><i>[Curaao: Beman presented Paul's Pre-Curaao comments (above). The LWG did 
not indicate great concern about the unlimited-precision integer question.</i></p>

<p><i>There is still considerable concern as to the usefulness of rational 
numbers in the context of the standard library. A straw vote was taken: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; 7-yes, 2-no, 
6-abstain.</i></p>

<p><i>Given the level of concern, the next step might be a paper &quot;explaining the 
explicit motivation for the usefulness of rational numbers in the context of the 
standard library.&quot;]</i></p>

<p><i>[Pre-Santa Cruz: Given that a credible unlimited-precision integer type is 
now progressing through Boost, Paul asks that his proposal be tabled until 
unlimited-precision integers are ready for standardization.&nbsp; See Pre-Curaao 
comments above.]</i></p>

<hr>

<h3>7. Threads</h3>

<p><b>Section:</b> ?&nbsp; <b>Status:</b> <a href="#Open">Open</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><br>
<b>Formal Proposal: </b></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>

<p><i>[Redmond: Bill presented the Boost Thread Library to the LWG.&nbsp; There 
was considerable interest and encouragement.]</i></p>

<p><i>[Pre-Curaao: Since Redmond, Bill 
Kempf has done considerable work on the documentation, Mac Murrett has 
contributed a port to the Mac, and Dave Moore has pending read/write lock, 
thread pool, and barrier contributions, all of which were known needs. Significant ongoing 
work includes addressing known issues with boost::thread, and adding 
cancellation and thread-attribute support.</i></p>

<p><i>There's been an increase in public awareness, including an article on 
Boost.Threads&nbsp; in CUJ, and non-Boost users and MT experts are offering both 
criticism and praise; evaluating that feedback continues.&nbsp; One of the 
byproducts of the feedback will be a list of features which might better be 
supported by language extensions.]</i></p>

<p><i>[Curaao: Dinkumware reports they are about to ship a multi-threading 
library, with the C++ portions based on the Boost Threads library. Pete Becker 
said that they view the need as for a &quot;toolkit&quot; approach, and Boost threads met 
that need.</i></p>

<p><i>The EWG and LWG jointly discussed 
the proposal. The decision was to proceed on separate but parallel LWG, CWG, and 
EWG tracks, and thus formal proposals and requests should be submitted as 
separate documents.</i></p>
<p><i>The proposal to the LWG for the TR should 
cover components which can be implemented today using only standard C++ with 
native threads libraries, without any compiler support or language extensions, 
but assuming that the CWG supplies appropriate standardese to describe uniform 
C++ execution in threaded environments.</i></p>
<p><i>The request to the Core Working Group should 
identify areas of concern to ensure uniform C++ execution in threaded 
environments. Although full standardese isn't discouraged, the point of asking 
the CWG for help is to tap their expertise in writing standardese affecting the 
core portion of the language.</i></p>
<p><i>The request to the Evolution Working Group 
should identify areas where a future C++ standard might better support 
multi-threading by adding language extensions. Although full standardese isn't 
discouraged, the point of asking the EWG for help is to tap their expertise in 
adding language enhancements.]</i></p>
<p><i>[Pre-Santa Cruz: A formal proposal is planned in time for the Oxford 
meeting.]</i></p>

<hr>

<h3>8. Hash tables</h3>

<p><b>Section:</b> 23&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b> 
Matt Austern&nbsp; <b>Date:</b> 17 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> <br>
<b>Formal Proposal: </b>
Revision 2:
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1399.html">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1399.html</a>,<br>
Original:
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326.html">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326.html</a></p>

<p>Hashed associative containers---hash tables---are one of the most frequently 
requested additions to the standard C++ library. Although hash tables have 
poorer worst-case performance than containers based on balanced trees, their 
performance is better in many real-world applications. </p>
<p>Hash tables are appropriate for this TR because they plug an obvious hole in 
the existing standard library. They are not intended for any one specific 
problem domain, style of programming, or community of programmers. I expect them 
to be used by a wide range of programmers. </p>
<p>There is extensive experience with hash tables implemented in C++ in the 
style of standard containers. Hash tables were proposed for the C++ standard in 
1995; the proposal was rejected for reasons of timing. Three independently 
written libraries, SGI, Dinkumware, and Metrowerks, now provide hashed 
associative containers as an extension. (The GNU C++ library includes hash 
tables derived from SGI's.) </p>
<p>The three shipping hash table implementations are similar, but not identical; 
this proposal is not identical to any of them. Some of the differences will be 
discussed in section III. An implementation of this proposal exists, but it is 
not yet in widespread use.</p>

<p><i>[Redmond:&nbsp; The LWG expressed great interest in the proposal, and 
complemented Matt on its completeness. There was some discussion of minor 
technical points.]</i></p>

<p><i>[Pre-Curaao: Matt has received technical 
comments and is preparing a minor update to the proposal.]</i></p>

<p><i>[Curaao: Given that there are several useful 
approaches to design and implementation of hash tables, the question was asked 
&quot;why not policy-based hash-tables?&quot; The short answer (from Per Andersson) 
was &quot;simplicity.&quot; Other LWG members said essentially the same thing, requiring, 
however, many more words to do so.]</i></p>

<p><i>[Santa Cruz: A formal proposal was submitted, and was reviewed by a LWG 
sub-group. They support the proposal, and have forwarded specific minor 
issues to Matt to be addressed in a final revision. The one contentious issue 
was the exact name of the classes. A straw vote in a joint meeting of the LWG 
and EWG showed no clear consensus, although a majority favored the traditional 
names as proposed. Matt and PJP will see if they can come up with more 
acceptable alternate names.]</i></p>

<hr>
<h3>9. Iterator adaptors</h3>
<p><b>Section:</b> 24&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b> 
Dave Abrahams, Jeremy Siek&nbsp; <b>Date:</b> 8 Apr 2002<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/utility/iterator_adaptors.htm">
www.boost.org/libs/utility/iterator_adaptors.htm</a><br>
<b>Formal Proposal: </b></p>
<p>The Iterator Adaptor library allows you transform an arbitrary ``base'' type 
into a standard-conforming iterator with the behaviors you choose. Doing so is 
especially easy if the ``base'' type is itself an iterator. The library also 
supplies several example adaptors which apply specific useful behaviors to 
arbitrary base iterators.</p>
<p>``Policy Adaptors and the Boost Iterator Adaptor Library'' (<a href="http://www.boost.org/libs/utility/iterator_adaptors.pdf">www.boost.org/libs/utility/iterator_adaptors.pdf</a>) 
is a technical paper describing this library and the powerful design pattern on 
which it is based. It was presented at the
<a href="http://www.oonumerics.org/tmpw01">C++ Template Workshop</a> at OOPSLA 
2001.</p>
<p>The proposal falls in the <i>filling gaps</i> category identified in
01-0028/N1314 as a target for the TR.</p>
<p><i>[Pre-Curaao: The submitters plan to refactor 
header files to meet the needs of the committee.]</i></p>

<p><i>[Curaao: Dave, with help from Jeremy, 
briefly presented Iterator Adaptors.&nbsp; If there is a LWG concern, it is that 
Iterator Adaptors are hard to get a handle on initially.</i></p>

<p><i>It was noted that Iterator Adaptors would 
benefit from named template parameters, although such a language feature is not 
a part of the proposal.&nbsp; There was concern that library based solutions for 
named template parameters be consistent across the entire standard library.</i></p>

<p><i>Straw vote: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; 12-yes, 0-no.]</i></p>

<p><i>[Pre-Santa Cruz: Dave and Jeremy plan to review and revise Iterator 
Adaptors in the next few weeks. They will report progress afterwards .]</i></p>

<hr>

<h3>10. Operators header</h3>
<p><b>Section:</b> 20&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b> 
Dave Abrahams, Jeremy Siek&nbsp; <b>Date:</b> 8 Apr 2002<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/utility/operators.htm">
www.boost.org/libs/utility/operators.htm</a><br>
<b>Formal Proposal: </b></p>
<p>This proposal supplies several sets of class templates which define operators 
at namespace scope in terms of a minimal number of fundamental operators 
provided by a template parameter class.</p>
<p>Overloaded operators for class types typically occur in groups. If you can 
write <code>x + y</code>, you probably also want to be able to write <code>x += 
y</code>. If you can write <code>x &lt; y,</code> you also want <code>x &gt; y, x &gt;= 
y,</code> and <code>x &lt;= y</code>. Moreover, unless your class has really 
surprising behavior, some of these related operators can be defined in terms of 
others (e.g. <code>x &gt;= y &lt;=&gt; !(x &lt; y)</code>). Replicating this boilerplate for 
multiple classes is both tedious and error-prone. The <cite>operators header</cite> 
templates help by generating operators for you at namespace scope based on other 
operators you've defined in your class.</p>
<p>The proposal falls in the <i>filling gaps</i> category identified in
01-0028/N1314 as a target for the TR.</p>

<p><i>[Curaao: Dave, with help from Jeremy, 
briefly presented the operators header.</i></p>

<p><i>Straw vote: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; 9-yes, 0-no.]</i></p>

<p><i>[Pre-Santa Cruz: still pending.]</i></p>

<hr>

<h3><a name="11">11</a>. Function object wrappers for deferred calls or callbacks</h3>
<p><b>Section:</b>&nbsp;20.3&nbsp; <b>Status:</b> <a href="#TR">TR</a>&nbsp; <b>Submitter:</b>&nbsp;Douglas 
Gregor&nbsp; <b>Date:</b> 9 Apr 2002<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/function/index.html">
www.boost.org/libs/function/index.html</a><br>
<b>Formal Proposal: </b>
Revised:
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1402.html">std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1402.html</a>,<br>
Original:
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1375.html">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1375.html</a></p>

<p>The proposal includes a family of class templates that are function object 
wrappers. The notion is similar to a generalized callback. It shares features 
with function pointers in that both define a call interface (e.g., a function 
taking two integer arguments and returning a floating-point value) through which 
some implementation can be called, and the implementation that is invoked may 
change throughout the course of the program. </p>
<p>Generally, any place in which a function pointer would be used to defer a 
call or make a callback, function object wrappers can be used instead to allow 
the user greater flexibility in the implementation of the target. Targets can be 
any 'compatible' function object (or function pointer), meaning that the 
arguments to the interface designated by the wrappers can be converted to the 
arguments of the target function object.</p>
<p>The current Boost.Function library, which is the basis for the proposal, has 
been found to be highly useful, and often appears on user's short lists of Boost 
libraries they would like to see standardized. Note that both Boost.Bind (<a href="#12">proposal 
12</a>) and Boost.Lambda are designed to work with, rather than replace, 
Boost.Function.</p>
<p>The proposal falls in the <i>filling gaps</i> category identified in
01-0028/N1314 as a target for the TR.</p>

<p><i>[Curaao: Dave Abrahams and Jaakko 
Jrvi briefly presented the proposal.</i></p>

<p><i>It was noted that while not required by the 
proposal, it would benefit from a language enhancement allowing a variable 
number of template parameters.</i></p>

<p><i>Straw vote: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; 12-yes, 0-no.]</i></p>

<p><i>[Pre-Santa Cruz: A formal proposal is in the pre-Santa Cruz mailing. It 
includes proposed text for the TR. Doug plans to be in Santa Cruz to answer 
questions about the proposal.] </i></p>

<p><i>[Santa Cruz: A LWG sub-group reviewed the formal proposal and raised minor 
issues, including need to reconcile details with the Tuples proposal. Doug, 
working with Gary Powell and Jaakko 
Jrvi, prepared a revised proposal (N1402) which was accepted by both the LWG 
and the full committee.] </i></p>

<hr>

<h3><a name="12">12</a>. Bind</h3>
<p><b>Section:</b>&nbsp;&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Peter 
Dimov&nbsp; <b>Date:</b> 16 Apr 2002<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/bind/bind.html">www.boost.org/libs/bind/bind.html</a><br>
<b>Formal Proposal: </b></p>

<p><b>bind</b> is a generalization of the standard functions <b>bind1st</b> and
<b>bind2nd</b>. It supports arbitrary function objects, functions, function 
pointers, and member function pointers, and is able to bind any argument to a 
specific value or route input arguments into arbitrary positions.</p>

<p>For example, the equivalent of <code>f(x, 5)</code> is:</p>

<blockquote>
  <pre>bind1st(ptr_fun(f), 5)(x)   // with current standard library
bind(f, 5, _1)(x)           // with bind</pre>
</blockquote>
<p><b>bind</b> does not place any requirements on the function object; in 
particular, it does not need the <b>result_type</b>, <b>first_argument_type</b> 
and <b>second_argument_type</b> standard typedefs, although it can take 
advantage of <b>result_type</b> to avoid specifying a return type explicitly. <b>
bind</b> works well with standard library algorithms. When combined with 
function object wrappers (<a href="#11">proposal 11</a>), the usefulness is even 
greater than the sum of the parts.</p>

<p>The proposal falls in the <i>filling gaps</i> category identified in
01-0028/N1314 as a target for the TR.</p>

<p><i>[Pre-Curaao:&nbsp; Peter comments that as a 
user, he does want a standard lambda library, but at the same time will 
settle for a standard bind if a standard lambda library just is not possible at 
this point in time.]</i></p>

<p><i>[Curaao: Jaakko 
Jrvi briefly presented the proposal. He explained 
that bind was originally part of the lambda library, and that it will 
interoperate seamlessly with the lambda library should that library be proposed 
for the standard.&nbsp; Since the LWG would not want to modify or remove bind 
should lambda become part of the standard library, Jaakko will verify that 
assertion with Peter Dimov.</i></p>

<p><i>It was noted that &quot;Bind (and Lambda) make the 
promise of the STL algorithms real&quot;, as helper functions do not have to be 
written far from the point of use.</i></p>

<p><i>There was tentative agreement that 
non-normative text be added to the appropriate sections of 20.3 (bind1st, etc.) 
indicating that bind is now the preferred solution.</i></p>

<p><i>Straw vote: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; 11-yes, 0-no.]</i></p>

<hr>

<h3>13. Tokenizer</h3>
<p><b>Section:</b>&nbsp;?&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John 
Bandela&nbsp; <b>Date:</b> 16 Apr 2002<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/tokenizer/index.htm">
www.boost.org/libs/tokenizer/index.htm</a><br>
<b>Formal Proposal: </b></p>

<p align="left">The <code>tokenizer</code> class template provides a container 
view of a series of tokens contained in a sequence. The sequence to parse and 
the TokenizerFunction which performs the parse are supplied either upon 
construction or via the assign member function.</p>
<p align="left">The <code>tokenizer</code> class template provides a flexible 
and easy way to break of a string or other character sequence into a series of 
tokens. For example, to break a phrase into words.</p>
<div align="left">
  <pre>   string s = &quot;This is,  a test&quot;;
   tokenizer&lt;&gt; tok(s);
   for(tokenizer&lt;&gt;::iterator beg=tok.begin(); beg!=tok.end();++beg)
   {
       cout &lt;&lt; *beg &lt;&lt; &quot;\n&quot;;
   }</pre>
</div>
<p>TokenizerFunctions <code>escaped_list_separator</code>, <code>
offset_separator</code>, and <code>char_delmiters_separator</code> are provided 
as part of the proposal.</p>

<p>The proposal falls in the <i>filling gaps</i> category identified in
01-0028/N1314 as a target for the TR, and eliminates the need to use std::strtok, 
with its associated problem of global state.</p>

<p><i>[Curaao: Jeremy Siek 
briefly presented the proposal.</i></p>

<p><i>Ichiro Koshida asked if tokenizer can handle 
multibyte character strings.&nbsp; The tentative answer is &quot;yes&quot;; a request has 
been made for test cases to verify that assertion.</i></p>

<p><i>There was a question as to performance 
compared to strtok().</i></p>

<p><i>Straw vote: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; 10-yes, 0-no.]</i></p>

<p><i>[Post-Curaao: John Bandela reports raw strtok calls are typically four 
times faster than raw tokenizer calls, while a strtok based application (copying 
the tokens to a vector) is typically twice as fast as the same code using 
tokenizer. Results vary a lot from compiler to compiler.]</i></p>

<hr>

<h3>14. Tuples</h3>
<p><b>Section:</b>&nbsp;?&nbsp; <b>Status:</b> <a href="#TR">TR</a>&nbsp; <b>Submitter:</b>&nbsp;Jaakko 
Jrvi&nbsp; <b>Date:</b> 16 Apr 2002<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/tuple/doc/tuple_users_guide.html">www.boost.org/libs/tuple/doc/tuple_users_guide.html</a><br>
<b>Formal Proposal: </b>
Revised: <a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf">std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf</a>,<br>
Original:
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf</a></p>

<p>A tuple (or <i>n</i>-tuple) is a fixed size collection of elements. Pairs, 
triples, quadruples etc. are tuples. Thus a tuple is a data object containing 
other objects as elements. These element objects may be of different types. </p>
<p>Tuples are convenient in many circumstances. For instance, tuples make it 
easy to define functions that return more than one value.</p>
<p>Some programming languages, such as ML, Python and Haskell, have built-in 
tuple constructs. Unfortunately C++ does not. To compensate for this 
&quot;deficiency&quot;, the Tuple proposal implements a tuple construct using templates.&nbsp; 
In addition to <code>tuple</code> itself, useful helpers such as <code>
make_tuple</code>, <code>tie</code> are included in the proposal.</p>
<p>A tuple type is an instantiation of the <code>tuple</code> template. The 
template parameters specify the types of the tuple elements. The Boost version 
supports tuples with 0-10 elements. If necessary, the upper limit can be 
increased up to, say, a few dozen elements. The data element can, effectively, 
be any C++ type which is <i>CopyConstructible.</i> If the tuple object is not 
constructed, the element types can be any C++ types.</p>

<p>The proposal falls in the <i>filling gaps</i> category identified in
01-0028/N1314 as a target for the TR.</p>

<p><i>[Curaao: Jaakko 
briefly presented the proposal.</i></p>

<p><i>It was noted that while not required by the 
proposal, it would benefit from a language enhancement allowing a variable 
number of template parameters.</i></p>

<p><i>Straw vote: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; 11-yes, 0-no.]</i></p>

<p><i>[Pre-Santa Cruz: A formal proposal is in the pre-Santa Cruz mailing. It 
includes proposed text for the TR.]</i></p>

<p><i>[Santa Cruz: A LWG sub-group reviewed the formal proposal and raised minor 
issues, including need to reconcile details with the Function Wrapper proposal.&nbsp;
</i>Jaakko<i>, working with Gary Powell and Doug Gregor, prepared a revised 
proposal (N1403) which was accepted by both the LWG and the full committee.]</i></p>

<hr>

<h3>15. Add file I/O functions taking filename arguments as std::strings </h3>
<p><b>Section:</b>&nbsp;27.8&nbsp; <b>Status:</b> <a href="#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Beman 
Dawes&nbsp; <b>Date:</b> 
15 Apr 2002<br>
<b>Type:</b> <a href="#Impure">Impure</a>&nbsp; <b>Requires:</b> <a href="#Std">Std C++</a>&nbsp;
<b>Existing-practice:</b> None&nbsp; <b>Implementation:</b> <a href="#No">No</a><br>
<b>Reference:</b><br>
<b>Formal Proposal: </b></p>

<p>The I/O functions identified below have signatures taking filename arguments
<code>s</code> as <code>const char*</code>. This is most inconvenient for modern 
C++ programs working with filenames as std::strings, and is a constant source of 
compile time errors.&nbsp; Although the fix is trivial (adding a call to <code>
std::string::c_str()</code>), it irritates users that the standard library 
doesn't provide for this common usage.</p>

<p>This problem was originally identified in library issue 105 from AFNOR.</p>

<p>Note that this proposal <b>does not</b> include <code>std::wstring</code> 
overloads. Discussion on the library reflector indicates such overloads would be 
extremely controversial, because there are no agreed upon semantics for the 
common case where the underlying operating system has no concept of wide 
character filenames.</p>

<p><b>Proposal:</b></p>

<p>To the member functions identified below, add a signature taking a <code>
const std::string&amp; s</code>, with effects defined as a call to the current 
function, with an <code>s</code> argument of <code>s</code><code>.c_str()</code>.</p>

<p>[lib.filebuf] 27.8.1.1 Template class basic_filebuf<br>
[lib.filebuf.members] 27.8.1.3 Member functions<br>
<br>
&nbsp;&nbsp;&nbsp; basic_filebuf open()<br>
<br>
[lib.ifstream] 27.8.1.5 Template class basic_ifstream<br>
[lib.ifstream.cons] 27.8.1.6 basic_ifstream constructors<br>
[lib.ifstream.members] 27.8.1.7 Member functions<br>
<br>
&nbsp;&nbsp;&nbsp; basic_ifstream constructor<br>
&nbsp;&nbsp;&nbsp; basic_ifstream open()<br>
<br>
[lib.ofstream] 27.8.1.8 Template class basic_ofstream<br>
[lib.ofstream.cons] 27.8.1.9 basic_ofstream constructors<br>
[lib.ofstream.members] 27.8.1.10 Member functions<br>
<br>
&nbsp;&nbsp;&nbsp; basic_ofstream constructor<br>
&nbsp;&nbsp;&nbsp; basic_ofstream open()<br>
<br>
[lib.fstream] 27.8.1.11 Template class basic_fstream<br>
[lib.fstream.cons] 27.8.1.12 basic_fstream constructors<br>
[lib.fstream.members] 27.8.1.13 Member functions<br>
<br>
&nbsp;&nbsp;&nbsp; basic_fstream constructor<br>
&nbsp;&nbsp;&nbsp; basic_fstream open()<br>
<br>
[depr.ios.members] D.6 Old iostreams members<br>
<br>
&nbsp;&nbsp;&nbsp; Three places; no change proposed.</p>

<p><i>[Curaao: Beman briefly presented the proposal.</i></p>

<p><i>There was discussion of various options for semantics for interpreting 
argument </i> <code>
const std::string&amp; s</code><i>:</i></p>

<p><i>1) s.c_str()</i></p>

<p><i>2) Treat s as multibyte character string if supported by operating system, 
else s.c_str().</i></p>

<p><i>3) Also provide std::wstring overload.</i></p>

<p><i>4) Generalize as a template&lt; typename S &gt; where s of type S must support 
s.c_str() returning a type convertible to const char *.</i></p>

<p><i>There was no support for options (3) and (4) because no one has been able 
to propose reasonable semantics. These options are listed here only as a record 
of discussion; they are dead-on-arrival without semantics applicable to all 
platforms.</i></p>

<p><i>Ichiro Koshida raised the question of multibyte character strings; the LWG 
was supportive of the intent but must consult I/O experts as to whether this is 
possible or makes sense.</i></p>

<p><i>Straw vote: &quot;Is the LWG interested enough to 
make it worthwhile for a formal proposal to be submitted?&quot; lots-yes, 0-no.]</i></p>

<p><i>[Pre-Santa Cruz: This proposal is on hold, pending the outcome of a couple 
of related projects:</i></p>

<ul>
  <li><i>Boost has accepted a Filesystem Library by Beman Dawes, which uses a 
  generalized path object rather than a string to represent file and directory 
  names. Ideas from this library may have some impact on an eventual proposal, 
  but it is too early to tell as the Boost library hasn't had time to mature 
  yet.</i></li>
  <li><i>The has been more discussion, both privately and on public newsgroups, 
  of wide-character string filenames. There is some interest in forming a group 
  to work on the issue. Any resulting proposal would almost certainly be 
  classified as innovation rather than existing practice, and thus not ready for 
  the TR.]</i></li>
</ul>

<p><i>[Santa Cruz: Although no formal vote was taken, there was considerable 
support in the LWG for not making piecemeal changes to existing Standard Library 
components in the first Library TR. Thus the proposal remains on hold.]</i></p>

<hr>
<h3>16. Date Time</h3>
<p><b>Section:</b> ??&nbsp; <b>Status:</b> <a href="#New">New</a>&nbsp; <b>Submitter:</b> 
Jeff Garland&nbsp; <b>Date:</b> 22 Sep 2002<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</a><br>
<b>Reference:</b> <a href="http://www.boost.org/libs/date_time/index.html">
www.boost.org/libs/date_time/index.html</a><br>
<b>Formal Proposal: </b></p>
<p>This proposal includes classes and functions for the manipulation of dates 
and times. The library separates the domain into the following concepts: </p>
<ul>
  <li>Time Points </li>
  <li>Time Durations </li>
  <li>Time Intervals </li>
  <li>Clocks </li>
  <li>Time systems (Calendars) </li>
</ul>
<p>This separation of concerns allows the library to support consistent 
extensions for different date-time systems. In addition to the type representing 
the domain concepts, the library builds on these concepts by providing 
programming aids such as <i>iterators</i> and <i>algorithms</i> useful for 
building date and time applications. </p>
<p>The current library provides an implementation of a concrete date system 
based on the ISO 8601 standard calendar system with a date range extending back 
to 1400 A.D. Some of the key classes include: <i>date</i>, <i>date_duration</i>,
<i>date_period</i>, <i>day_clock</i>, and <i>gregorian_calendar</i>. For time 
programming the library offers a non-adjusted counted time system. Some of the 
key classes include: <i>ptime(posix time)</i>, <i>time_duration</i>, <i>
time_period</i>, and others. </p>
<p>The manipulation of dates and times is an extremely common problem in 
building applications. Many date-time libraries are available and are utilized 
widely by C++ programmers. </p>
<p>This proposal would benefit from the adoption of a 64-bit integer type. </p>
<p>The proposal falls in the filling gaps category identified in 01-0028/N1314 
as a target for the TR.</p>

<p><i>[Santa Cruz: Jeff Garland presented the Date Time library to the LWG.&nbsp; 
There was considerable interest, and Jeff was asked to submit a formal proposal.&nbsp; 
In addition to the current Boost components, civil time was of interest to LWG 
members.]</i></p>

<hr>

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

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