----- Original Message ----- From: "Beman Dawes" <[EMAIL PROTECTED]> To: "Boost.org mailing list" <[EMAIL PROTECTED]> Sent: Monday, May 07, 2001 9:05 AM Subject: [boost] C++ committee Library Technical Report progress report > The C++ standards committee met last week in Copenhagen. The Library > Working Group (LWG) is moving forward with preliminaries for a Library > Technical Report (TR). The necessary ISO paperwork is underway. > > (A type 2 Technical Report is non-normative. Library suppliers are not > obligated to implement a TR, but it provides an standard specification for > those who do choose to implement it. The TR also serves to notify the C++ > community of future direction; the intent is to include the contents of the > TR in a future standard.) > > (The follow is my interpretation of the LWG's direction, so is subject to > change. Where I give examples, they are examples that came up in the LWG > discussions.) > > * The time line for the TR is two years, with the intent to continue the > process on an ongoing basis, presumably by continuing work on the next TR > even as the first one is completed. > > * Libraries which cannot be implemented on all platforms will be > accepted. For example, threads or TCP/IP. Such libraries will simply be > non-normative even in a future standard (and thus never required), rather > than the standard trying to dictate when a vendor is required to supply the > library. Libraries may be supplied in fully functional form, not at all, or > as a non-functional stub. (Non-functional implementations would be useful > for a threads library, for example, so that other libraries could use it > without change even on a platform without threads.) There will be a way > (possibly via macro) to tell which form (functional/none/non-functional) is > supplied by a given implementation. > > * Primary interest is for proposals in the following areas: > > -- Filling in gaps in the current standard library. > > -- Text processing. For example, regular expressions. > > -- Numerics. (No examples were given, IIRC.) > > -- Graphics. Just the ability to draw, not a GUI. > > -- System Programming. Access to operating system facilities, > such as threads, directories, etc. > > -- Networking. For example, TCP/IP, sockets. > > -- Language bindings. Particularly tools which support > bindings in general, rather than bindings to a particular > language. > > * For a proposal to be considered, it must be well-formed, represent > existing practice (with reference implementation), and not break existing > code. > > There was some discussion of where proposals might come from. Boost was > mentioned, of course. (The bulk of the LWG are Boost members, and the > remainder tend to be very supportive of Boost.) The only other mention was > a group of library suppliers who may propose hash tables and singly linked > lists based on their current implementations. > > --Beman > > > To unsubscribe, send email to: <mailto:[EMAIL PROTECTED]> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > >
