Doc. no. J16/03-0058=WG21/N1475
Date: 25 April 2003
Project: Programming Language C++
Reply to: Beman Dawes <bdawes@acm.org>
1. C99 Library Additions to C++
2. Type Traits
3. Regular Expressions
4. General Purpose Smart Pointers
5. Random Numbers
6. Rational Numbers
7. Threads
8. Hash tables
9. Iterator adaptors
10. Operators header
11. Function object wrappers for deferred calls or callbacks
12. Enhanced Binder
13. Tokenizer
14. Tuples
15. Add file I/O functions taking filename arguments as
std::strings
16. Date Time
17. Mathematical Special Functions
18. Enhanced Member Pointer Adaptor
19. Reference Wrapper
20. Uniform method for computing function object return types
21. Fixed Size Array Wrapper
22. New Iterator Requirements
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.
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.
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.
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.
Hold - Work on a formal proposal is not underway at this time. The LGW will devote no more time to the proposal until the proposal is re-opened.
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.
Pure - The proposal is not expected to break source or binary compatibility for existing uses or implementations of the standard library.
Impure - The proposal is expected to break source or binary compatibility for existing uses or implementations of the standard library.
If there is some doubt, a proposal should be classified as impure.
Std C++ - Both the interface and a reasonable implementation require only standard C++ as defined in ISO/IEC 14882:1998.
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.
For proposals representing substantial existing practice, list suppliers (in abbreviated form). For widely available extensions like hash tables, specify "Many".
None - Indicates there is no widely available existing practice.
Yes - There is a working reference implementation available. [What does "available" mean? Does it include "available for a million dollar fee", "if you sign an obnoxious NDA", or "if you aren't a competitor"? I'd say "no" to all of those. On the other hand, I certainly would expect the reference implementation to be copyrighted and not necessarily freely available for all uses. Perhaps "available for inspection by LWG members?"]
No - Doesn't meet the above criteria.
One or more references to the documentation and reference implementation, preferable in the form of URLs. URLs should be spelled out in full so that they are readable on printed copies of this Proposals List.
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.
Section: 18.7 Status: Open Submitter:
P.J. Plauger Date: 3 Feb 2002
Type: Pure Requires: Std C++
Existing-practice: Many Implementation: Yes
Reference:
www.dinkumware.com/refxc.html,
ISO/IEC 9899:1999 Programming Language C
Formal Proposal: Revised:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1372.txt,
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt,
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.]
[pre-Santa Cruz: Per the request of the EWG and LWG, the proposal was revised and included in the post-Curaçao mailing.]
[Santa Cruz: The key aspects of the revised proposal were presented at an evening technical session. PJP and Matt Austern will work toward a formal proposal for the Oxford meeting.]
Section: 18 Status: TR 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:
Revised: N1424/03-0006
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1424.htm
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1345.html
[N1424 was accepted at the Santa Cruz meeting.]
Section: 21 Status: TR 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: Revised: N1429/03-0011
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1429.htm
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1386.htm
[N1429 was accepted at the Santa Cruz meeting.]
Section: 20 Status: TR Submitter:
Peter Dimov, 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/shared_ptr.htm
Formal Proposal: Revised: N1450/03-0032
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html
Original: N1431/03-0013
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1431.html
[N1450 was accepted at the Santa Cruz meeting.]
Section: 26 Status: TR 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: Revised: N1452/03-0034
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html
Original: N1398/02-0056
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1398.html
[N1452 was accepted at the Santa Cruz meeting.]
Section: 26 Status: Hold 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."]
[Pre-Santa Cruz: Given that a credible unlimited-precision integer type is now progressing through Boost, Paul asks that his proposal be tabled until unlimited-precision integers are ready for standardization. See Pre-Curaçao comments above.]
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.]
[Pre-Santa Cruz: A formal proposal is planned in time for the Oxford meeting.]
[Post-Oxford: A formal proposal has been delayed by work on refinements dealing with usage issues such as thread priorities. Two additional developers are now helping with the project.]
Section: 23 Status: TR Submitter:
Matt Austern Date: 17 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Many Implementation: Yes
Reference:
Formal Proposal: Revision 4: N1456/03-0038
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1456.html
Revision 3:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1443.html,
Revision 2:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1399.html,
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326.html
[N1456 was accepted at the Oxford meeting.]
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: N1476/03-0059
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1475.html
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.]
[Pre-Santa Cruz: Dave and Jeremy plan to review and revise Iterator Adaptors.]
[Post-Oxford: A formal proposal (N1476) is promised for the Post-Oxford mailing.]
Section: 20 Status: Hold 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.]
[Post-Oxford: Dave reports there are no plans to continue with this proposal due to lack of time/interest on his part. He says that the need is "definitely not redundant or replaced. If someone else cares enough, they should propose it."]
Section: 20.3 Status: TR 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:
Revised: N1402/02-0060
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1402.html,
Original: N1375/02-0033
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1375.html
[N1402 was accepted at the Santa Cruz meeting.]
Section: Status: TR Submitter: Peter
Dimov, Doug Gregor, Jakko Järvi, Gary Powell Date: 16 Apr 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/bind/bind.html
Formal Proposal: Revised: N1455/03-0037
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1455.htm
Original: N1438/03-0020
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1438.htm
[N1455 was accepted at the Oxford meeting.]
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.]
Section: ? Status: TR 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:
Revised: N1403 std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf,
Original: N1382
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf
[N1403 was accepted at the Santa Cruz meeting.]
Section: 27.8 Status: Hold 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.
[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.]
[Pre-Santa Cruz: This proposal is on hold, pending the outcome of a couple of related projects:
[Santa Cruz: Although no formal vote was taken, there was considerable support in the LWG for not making piecemeal changes to existing Standard Library components in the first Library TR. Thus the proposal remains on hold.]
Section: ?? Status: Open Submitter:
Jeff Garland Date: 22 Sep 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/date_time/index.html
Formal Proposal:
This proposal includes classes and functions for the manipulation of dates and times. The library separates the domain into the following concepts:
This separation of concerns allows the library to support consistent extensions for different date-time systems. In addition to the type representing the domain concepts, the library builds on these concepts by providing programming aids such as iterators and algorithms useful for building date and time applications.
The current library provides an implementation of a concrete date system based on the ISO 8601 standard calendar system with a date range extending back to 1400 A.D. Some of the key classes include: date, date_duration, date_period, day_clock, and gregorian_calendar. For time programming the library offers a non-adjusted counted time system. Some of the key classes include: ptime(posix time), time_duration, time_period, and others.
The manipulation of dates and times is an extremely common problem in building applications. Many date-time libraries are available and are utilized widely by C++ programmers.
This proposal would benefit from the adoption of a 64-bit integer type.
The proposal falls in the filling gaps category identified in 01-0028/N1314 as a target for the TR.
[Santa Cruz: Jeff Garland presented the Date Time library to the LWG. There was considerable interest, and Jeff was asked to submit a formal proposal. In addition to the current Boost components, civil time was of interest to LWG members.]
[Pre-Oxford: A formal proposal is still planned; no target date has been set yet.]
Section: ? Status: TR Submitter:
Walter E. Brown Date: 24 Feb 2003
Type: ? Requires: ?
Existing-practice: ? Implementation: ?
Reference:
Formal Proposal: N1422/03-0004
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1422.html
[N1422 was accepted at the Oxford meeting.]
Section: 20.3 Status: TR Submitter:
Peter Dimov Date: 28 Feb 2003
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/mem_fn/
Formal Proposal: N1432/03-0014
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1432.html
[N1432 was accepted at the Oxford meeting.]
Section: 20.3 Status: TR Submitter:
Douglas Gregor Date: 28 Feb 2003
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/bind/ref.html
Formal Proposal: Revised: N1453/03-0035
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1453.htm
Original: N1436/03-0018
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1436.htm
[N1453 was accepted at the Oxford meeting.]
Section: 20.3 Status: TR Submitter:
Douglas Gregor Date: 27 Feb 2003
Type: Pure Requires: Std C++
Existing-practice: Yes Implementation: Yes
Reference:
www.boost.org/libs/lambda/,
spirit.sourceforge.net/index.php?doc=docs/phoenix v1 0/index.html.
Formal Proposal: Revised: N1454/03-0036
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.htm
Original: N1437/03-0019
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1437.htm
[N1454 was accepted at the Oxford meeting.]
Section: 23 Status: New Submitter:
Alisdair Meredith Date: 25 Apr 2003
Type: Pure Requires: Std C++
Existing-practice: Yes Implementation: Yes
Reference:
www.boost.org/libs/array
Formal Proposal: N1479/03-0062
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1479.htm
This is Nicolai Josuttis' Boost version of the fixed-size array wrapper described by Bjarne Stroustrup, Matt Austern, and Nicolai Josuttis in their respective books.
[N1479 is promised for the post-Oxford mailing]
Section: 24 Status: New Submitter:
Jeremy Siek Date: 25 Apr 2003
Type: ? Requires: Std C++
Existing-practice: ? Implementation: ?
Reference:
Formal Proposal: N1477/03-0060
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1477.html
Also see [9] Iterator adaptors proposal.
[N1477 is promised for the post-Oxford mailing]
Revised April 25, 2003
--- End ---