Doc. no.   J16/02-0019=WG21/N1361
Date:        30 April 2002
Project:     Programming Language C++
Reply to:   Beman Dawes <bdawes@acm.org>

Library Technical Report Proposals and Issues List (Revision 3)

Introduction

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

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.  Working group schedules will be set so that LWG members can participate in EWG discussions of these proposals.

Entries contain references

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

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.  As a proposal progresses, it will take the form of a regular numbered committee document.

Standardese

Final acceptance of a proposal requires specific TR wording in full standardese.

Library developers would be discouraged from submitting proposals if the initial proposal had to be written in standardese, since the submitter would not yet know if the proposal stood even a chance of acceptance.  To avoid this problem, the LWG does not require preliminary proposals be written in standardese.  Actual acceptance, however, always requires full TR wording in standardese.

Proposal Status

New - The proposal or issue has not yet been reviewed by the LWG. The proposal should not be construed as the view of LWG.

Open - The LWG has discussed the proposal but is not yet ready to move the proposal forward. There are several possible reasons for open status: for example, the LWG may wish to study the proposal further, is awaiting additional material from the submitter, has requested modifications to the proposal, or is awaiting final TR wording.  Italicized notes by the list maintainer serve to remind the LWG of the details of the current status. 

Dup - The LWG has reached consensus that the proposal is a duplicate of another proposal, and will not be further dealt with. A Rationale identifies the duplicated proposal number.

Rejected - The LWG has reached consensus that the proposal should not be accepted for the TR. A Rationale discusses the LWG's reasoning.

Review - Exact wording for the TR is now available for review.

Ready - The LWG has reached consensus that the proposal is ready to forward to the full committee for inclusion in the TR.

TR - The full committee has accepted the proposal for inclusion in the Library Technical Report.

Type

Pure - The proposal is not expected to break source or binary compatibility for existing uses or implementations of the standard library.

Impure - The proposal is expected to break source or binary compatibility for existing uses or implementations of the standard library.

If there is some doubt, a proposal should be classified as impure.

Requires

Std C++ - Both the interface and a reasonable implementation require only standard C++ as defined in ISO/IEC 14882:1998.

Extension - Either the interface or reasonable implementations require a core language change or extension.

Compiler - The interface is standard C++, but no reasonable implementation is possible without compiler support. For example, a function template which determines if a structure is a POD requires compiler support but not a core language change.

Native - The interface is standard C++, but implementations will normally use platform dependent native libraries. Thus such a proposal may not be implementable on all hosted C++ platforms.

Existing-practice

For proposals representing substantial existing practice, list suppliers (in abbreviated form). For widely available extensions like hash tables, specify "Many".

None - Indicates there is no widely available existing practice.

Implementation

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

No - Doesn't meet the above criteria.

Reference

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

Formal Proposal

One or more references to the actual numbered committee document which contains the formal proposal in full standardese, preferable in the form of URLs.  URLs should be spelled out in full so that they are readable on printed copies of this Proposals List.

Left blank if a formal proposal has not yet been received.

Most formal proposals go through several revisions.  The document number for each revision should be listed, with the most recent first.

Proposals and Issues

1. C99 Library Additions to C++

Section: 18.7  Status: Open  Submitter: P.J. Plauger  Date: 3 Feb 2002
Type: Pure  Requires: Std C++  Existing-practice: Many  Implementation: Yes
Reference: std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt,
www.dinkumware.com/refxc.html, ISO/IEC 9899:1999 Programming Language C
Formal Proposal:

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. Document 02-0012/N1354 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 www.dinkumware.com/refxc.html, 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.

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

[Redmond:  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.]

[Pre-Curaçao: PJP submitted his comprehensive proposal, and Dawes withdrew the Boost proposal.]

[Curaçao: 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.

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.

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.

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++.  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.]

2. Type Traits

Section: 18  Status: Open  Submitter: John Maddock  Date: 4 Oct 2001
Type: Pure  Requires: Compiler  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/type_traits/index.htm
Formal Proposal: std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1345.htm

The proposal (02-0003/N1345) supplies template classes that describe the fundamental properties of a type; each class represents a single type property or a single type transformation.

Some of the type categorizations require compiler support.

The Boost Type Traits Library is well-known and widely used.  See www.boost.org/libs/type_traits/c++_type_traits.htm for an article appearing in Dr. Dobb's Journal.  Once type traits become available, a significant percentage (10-20%) of template-base libraries use them directly, while up to one-third use type traits indirectly (based on a Boost library dependency analysis.)  Several other libraries (Loki, for example) have also invented type traits mechanisms.

Type traits falls into the Infrastructure category identified in 01-0028/N1314 as a target for the TR. Type traits allows easy detection of certain type errors (is a template class parameter a POD as required?) that are otherwise difficult or impossible to detect.

Acknowledgements: Type traits is based on initial contributions by Steve Cleary, Beman Dawes, Aleksey Gurtovoy, Howard Hinnant, Jesse Jones, Mat Marcus, John Maddock and Jeremy Siek. Later contributions have come from many others. John Maddock is the chief architect and library maintainer.

[Redmond: The LWG expressed great interest in the proposal query.  In response to a query about Loki TypeTraits, Andrei Alexandrescu said he supports the Boost proposal.]

[Pre-Curaçao: John Maddock submitted his formal proposal.]

[Curaçao: 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.

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.

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 "Compiler Support" section of the current proposal.]

3. Regular Expressions

Section: 21  Status: Open  Submitter: John Maddock  Date: 4 Oct 2001
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/regex/index.htm
Formal Proposal:

This proposal provides full regular expression facilities, including wchar_t support. Wherever possible, compatibility has been maintained with other libraries, particularly the Henry Spencer, Perl, GNU, and POSIX regular expression libraries. The proposal contains POSIX compatibility and other subsidiary functions which the LWG may wish to exclude.

An easy-to-read introduction appeared in Dr. Dobb's Journal, see www.ddj.com/articles/2001/0110/0110a/0110a.htm

A possible criticism is that more convenience functions interoperating with std::basic_string are needed.  Darin Adler at Boost is working on a set of string algorithms which include overloads for regular expressions. This approach uniformly supplies useful functionality, regardless of whether arguments are plain strings or regular expressions.

Regular expressions are important both in theory and practice. They fall into one of the domains (text processing) identified in 01-0028/N1314 as a target for the TR. The regex++ library is well known, and was in use before being accepted as a Boost library. Based on both user feedback and site page view statistics, regex++ is among the most heavily used Boost libraries.

[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.]

[Pre-Curaçao: 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 "uses some interesting implementation techniques," and they may possibly decide on a joint proposal.]

[Curaçao: A brief discussion resulted in these action items:

• John should query the LWG via the lib reflector with his matching rules questions.
• John should proceed with his formal proposal.
• Jeremy will query John with Nathan's question about supplying both "push" and "pull" interfaces.]

4. Smart Pointers

Section: 20  Status: Open  Submitter: Peter Dimov, Darin Adler, Greg Colvin, Beman Dawes  Date: 4 Oct 2001
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/smart_ptr/index.htm
Formal Proposal:

The proposal supplies four smart pointer class templates (which interoperate with auto_ptr when appropriate):

Several common questions are answered by www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ

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

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

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

[Pre-Curaçao: 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.

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.

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

[Curaçao: The LWG expressed serious concerns about the proposal, and about other smart pointer issues:

• 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.
   
• Because of the need for a single smart pointer to recommend for everyday use, and for interoperability between third-party libraries, shared_ptr 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.
   
• 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.
   
• 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; scoped_ptr, scoped_array, and shared_array were not viewed favorably by many LWG members.
   
• LWG members are very concerned that "you don't have to pay for what you don't use." 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.
   
• LWG members are concerned about usability and flexibility of designs with multiple template policy parameters.  A single policy parameter, with policy composition by chained inheritance, would seem to have usability, flexibility, and inter-policy communication advantages.
   
• 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.  (The 1/2 vote was from someone undecided.)
   
• There was a bit of discussion and show of hands on non-member versus member functions.  No clear guidance resulted; the existing use of member functions in std::auto_ptr and the Boost smart pointers muddied the question.

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

5. Random Numbers

Section: 26  Status: Open  Submitter: Jens Maurer  Date: 4 Oct 2001
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/random/index.html
Formal Proposal:

This proposal provides a framework for random number generators and distributions. Both the RNG's and distributions have well-defined properties for use in demanding numerics and security domains, as well as in everyday programming. Adaptors to meet RandomNumberGenerator requirements (25.2.11 [lib.alg.random.shuffle]) and input iterator requirements (24.1.1 [lib.input.iterators]) are also provided.

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

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

[Pre-Curaçao: There have been discussions with users regarding some details of the interface. Also, Matthias Troyer claims to have a way to supply a uniform "unsigned int" constructor for each generator, which would help exchangeability of the generators quite a lot.

There is an outstanding question of how to express the semantics of the more complicated, but better, generators in standardese.]

[Curaçao: Jens led a brief discussion resulting in these action items:

• Jens will work on a formal proposal
• Beman will query Andy about how to describe generator semantics in standardese.

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

6. Rational Numbers

Section: 26  Status: Open  Submitter: Paul Moore  Date: 4 Oct 2001
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/rational/index.html
Formal Proposal:

This proposal includes class template rational, and related support such as exception class bad_rational, and function template rational_cast.

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

Rational numbers are important both in theory and practice. Questions and bug reports indicate that the class sees actual use. It falls into one of the domains (numerics) identified in 01-0028/N1314 as a target for the TR.

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

[Pre-Curaçao: 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.

Paul also comments that without an unlimited-precision integer type on which to base the rational class, the usefulness of rational<> is drastically diminished. Both double and rational<int> 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<int>, they are *not* well known. On the contrary, the sort of people who might use rational<int> are very likely to completely miss the fact that there are such problems.

It's arguable that these sort of issues make rational<> 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,  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.]

[Curaçao: Beman presented Paul's Pre-Curaçao comments (above). The LWG did not indicate great concern about the unlimited-precision integer question.

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

Given the level of concern, the next step might be a paper "explaining the explicit motivation for the usefulness of rational numbers in the context of the standard library."]

7. Threads

Section: ?  Status: Open  Submitter: William Kempf  Date: 4 Oct 2001
Type: Pure  Requires: Native  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/thread/doc/index.html
Formal Proposal:

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

The very public development process, with over one hundred people contributing comments and insights, ensured that a wide-range of concerns were exposed, and resulted in a much stronger library.  The documentation includes a great deal of rationale for important design decisions. 

The proposal is suitable for a wide range of hosted C++ environments, but is intended to be an optional component of the C++ Standard Library since implementors may not wish to support platforms where concurrent programming support is limited, non-existent, or unimportant.  The proposal has been implemented on UNIX using POSIX threads, and Windows using both the native Win32 threads and POSIX threads.

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

[Redmond: Bill presented the Boost Thread Library to the LWG.  There was considerable interest and encouragement.]

[Pre-Curaçao: 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.

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

[Curaçao: 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 "toolkit" approach, and Boost threads met that need.

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.

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.

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.

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.

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

8. Hash tables

Section: 23  Status: Open  Submitter: Matt Austern  Date: 17 Oct 2001
Type: Pure  Requires: Std C++  Existing-practice: Many  Implementation: Yes
Reference:
Formal Proposal: std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326.html

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.

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.

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

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.

[Redmond:  The LWG expressed great interest in the proposal, and complemented Matt on its completeness. There was some discussion of minor technical points.]

[Pre-Curaçao: Matt has received technical comments and is preparing a minor update to the proposal.]

[Curaçao: Given that there are several useful approaches to design and implementation of hash tables, the question was asked "why not policy-based hash-tables?" The short answer (from Per Andersson) was "simplicity." Other LWG members said essentially the same thing, requiring, however, many more words to do so.

Matt was encouraged to submit the revision of his proposal.]

9. Iterator adaptors

Section: 24  Status: Open  Submitter: Dave Abrahams, Jeremy Siek  Date: 8 Apr 2002
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/utility/iterator_adaptors.htm
Formal Proposal:

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.

``Policy Adaptors and the Boost Iterator Adaptor Library'' (www.boost.org/libs/utility/iterator_adaptors.pdf) is a technical paper describing this library and the powerful design pattern on which it is based. It was presented at the C++ Template Workshop at OOPSLA 2001.

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

[Pre-Curaçao: The submitters plan to refactor header files to meet the needs of the committee.]

[Curaçao: Dave, with help from Jeremy, briefly presented Iterator Adaptors.  If there is a LWG concern, it is that Iterator Adaptors are hard to get a handle on initially.

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

Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 12-yes, 0-no.]

10. Operators header

Section: 20  Status: Open  Submitter: Dave Abrahams, Jeremy Siek  Date: 8 Apr 2002
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/utility/operators.htm
Formal Proposal:

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.

Overloaded operators for class types typically occur in groups. If you can write x + y, you probably also want to be able to write x += y. If you can write x < y, you also want x > y, x >= y, and x <= y. Moreover, unless your class has really surprising behavior, some of these related operators can be defined in terms of others (e.g. x >= y <=> !(x < y)). Replicating this boilerplate for multiple classes is both tedious and error-prone. The operators header templates help by generating operators for you at namespace scope based on other operators you've defined in your class.

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

[Curaçao: Dave, with help from Jeremy, briefly presented the operators header.

Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 9-yes, 0-no.]

11. Function object wrappers for deferred calls or callbacks

Section: 20.3  Status: Open  Submitter: Douglas Gregor  Date: 9 Apr 2002
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/function/index.html
Formal Proposal:

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.

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.

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 (proposal 12) and Boost.Lambda are designed to work with, rather than replace, Boost.Function.

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

[Curaçao: Dave Abrahams and Jaakko Järvi briefly presented the proposal.

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

Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 12-yes, 0-no.]

12. Bind

Section:   Status: Open  Submitter: Peter Dimov  Date: 16 Apr 2002
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/bind/bind.html
Formal Proposal:

bind is a generalization of the standard functions bind1st and bind2nd. 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.

For example, the equivalent of f(x, 5) is:

bind1st(ptr_fun(f), 5)(x)   // with current standard library
bind(f, 5, _1)(x)           // with bind

bind does not place any requirements on the function object; in particular, it does not need the result_type, first_argument_type and second_argument_type standard typedefs, although it can take advantage of result_type to avoid specifying a return type explicitly. bind works well with standard library algorithms. When combined with function object wrappers (proposal 11), the usefulness is even greater than the sum of the parts.

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

[Pre-Curaçao:  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.]

[Curaçao: Jaakko Järvi 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.  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.

It was noted that "Bind (and Lambda) make the promise of the STL algorithms real", as helper functions do not have to be written far from the point of use.

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.

Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 11-yes, 0-no.]

13. Tokenizer

Section: ?  Status: Open  Submitter: John Bandela  Date: 16 Apr 2002
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/tokenizer/index.htm
Formal Proposal:

The tokenizer 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.

The tokenizer 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.

   string s = "This is,  a test";
   tokenizer<> tok(s);
   for(tokenizer<>::iterator beg=tok.begin(); beg!=tok.end();++beg)
   {
       cout << *beg << "\n";
   }

TokenizerFunctions escaped_list_separator, offset_separator, and char_delmiters_separator are provided as part of the proposal.

The proposal falls in the filling gaps 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.

[Curaçao: Jeremy Siek briefly presented the proposal.

Ichiro Koshida asked if tokenizer can handle multibyte character strings.  The tentative answer is "yes"; a request has been made for test cases to verify that assertion.

There was a question as to performance compared to strtok().

Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 10-yes, 0-no.]

[Post-Curaçao: 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.]

14. Tuples

Section: ?  Status: Open  Submitter: Jaakko Järvi  Date: 16 Apr 2002
Type: Pure  Requires: Std C++  Existing-practice: Boost  Implementation: Yes
Reference: www.boost.org/libs/tuple/doc/tuple_users_guide.html
Formal Proposal:

A tuple (or n-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.

Tuples are convenient in many circumstances. For instance, tuples make it easy to define functions that return more than one value.

Some programming languages, such as ML, Python and Haskell, have built-in tuple constructs. Unfortunately C++ does not. To compensate for this "deficiency", the Tuple proposal implements a tuple construct using templates.  In addition to tuple itself, useful helpers such as make_tuple, tie are included in the proposal.

A tuple type is an instantiation of the tuple 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 CopyConstructible. If the tuple object is not constructed, the element types can be any C++ types.

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

[Curaçao: Jaakko briefly presented the proposal.

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

Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 11-yes, 0-no.]

15. Add file I/O functions taking filename arguments as std::strings

Section: 27.8  Status: Open  Submitter: Beman Dawes  Date: 15 Apr 2002
Type: Impure  Requires: Std C++  Existing-practice: None  Implementation: No
Reference:
Formal Proposal:

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

This problem was originally identified in library issue 105 from AFNOR.

Note that this proposal does not include std::wstring 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.

Proposal:

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

[lib.filebuf] 27.8.1.1 Template class basic_filebuf
[lib.filebuf.members] 27.8.1.3 Member functions

    basic_filebuf open()

[lib.ifstream] 27.8.1.5 Template class basic_ifstream
[lib.ifstream.cons] 27.8.1.6 basic_ifstream constructors
[lib.ifstream.members] 27.8.1.7 Member functions

    basic_ifstream constructor
    basic_ifstream open()

[lib.ofstream] 27.8.1.8 Template class basic_ofstream
[lib.ofstream.cons] 27.8.1.9 basic_ofstream constructors
[lib.ofstream.members] 27.8.1.10 Member functions

    basic_ofstream constructor
    basic_ofstream open()

[lib.fstream] 27.8.1.11 Template class basic_fstream
[lib.fstream.cons] 27.8.1.12 basic_fstream constructors
[lib.fstream.members] 27.8.1.13 Member functions

    basic_fstream constructor
    basic_fstream open()

[depr.ios.members] D.6 Old iostreams members

    Three places; no change proposed.

[Pre-Curaçao:  If the LWG is feels favorably toward the proposal, Beman will provide full standardese, and provide a sample implementation.]

[Curaçao: Beman briefly presented the proposal.

There was discussion of various options for semantics for interpreting argument const std::string& s:

1) s.c_str()

2) Treat s as multibyte character string if supported by operating system, else s.c_str().

3) Also provide std::wstring overload.

4) Generalize as a template< typename S > where s of type S must support s.c_str() returning a type convertible to const char *.

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.

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.

Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" lots-yes, 0-no.]

Revised April 30, 2002

--- End ---