<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-0019=WG21/N1361<br>
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 30 April 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 3)</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://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt</a>,<br>
<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></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>

<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.htm">
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1345.htm</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>

<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></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>[Redmond: The LWG expressed great interest in the proposal query. Members 
asked if it was POSIX compatible (answer: yes). Matt Austern said he thought 
other's might also make regular expression proposals.]</i></p>

<p><i>[Pre-Curaao: John has started to draft a 
formal proposal. He needs to know the LWG's preference for which matching 
rules to support, and will ask for feedback on the library reflector. 
Also, John has been in contact with the author of GRETA (from Microsoft 
research), which &quot;uses some interesting implementation techniques,&quot; and 
they may possibly decide on a joint proposal.]</i></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>

<hr>

<h3>4. Smart Pointers</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/index.htm">www.boost.org/libs/smart_ptr/index.htm</a><br>
<b>Formal Proposal: </b></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>

<p><i>[Pre-Curaao: Peter Dimov and Darin Adler have taken over primary 
responsibility, with continued help from Greg and Beman. Peter contributed a 
major, but compatible, upgrade which includes weak_ptr.<br>
<br>
Because of the importance of the proposal, a constant stream of suggestions, 
comments, and questions appear on the Boost lists. In effect, the library is 
under continuous review, and use is extremely wide-spread. <br>
<br>
Andrei Alexandrescu kindly participated in Boost discussions of Loki::SmartPtr, 
and how it might be reformulated to replace the Boost smart pointers. Based on 
those discussions, we continue to believe the Boost smart pointers are the best 
choice for the TR.]</i></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.<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.<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.<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.<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 weak_ptr, for example, is viewed as a serious problem.<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.<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.)<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.</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>

<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>[Pre-Curaao: There have been discussions with users regarding some 
details of the interface.&nbsp;Also, Matthias Troyer claims to have a way to supply a 
uniform &quot;unsigned int&quot; constructor for each generator, which would help 
exchangeability of the generators quite a lot.</i></p>

<p><i>There is an outstanding question of how to express the semantics of the 
more complicated, but better, generators in standardese.]</i></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>

<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>

<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>Given the schedule for the TR, it would be 
helpful if the LWG and CWG documents were available next fall for the Santa Cruz 
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>
<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>Matt was encouraged to submit the revision of his proposal.]</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>

<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>

<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="#Open">Open</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></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>

<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="#Open">Open</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></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>

<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>[Pre-Curaao:&nbsp; If the LWG is feels 
favorably toward the proposal, Beman will provide full standardese, and provide 
a sample implementation.]</i></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>

<hr>

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

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