- Boost-announce - lists.boost.org

Formal review: Optional library
by Douglas Gregor 09 Dec '02

09 Dec '02

The formal review of Fernando Cacciola's Optional library begins today and runs until the end of Wednesday, December 18. The Optional library provides a class template "optional<T>" that either contains a value of type "T" or contains no value (i.e., having a value is optional). It is useful, for example, as the return type of functions that may or may not return a value, depending on their inputs. The Optional library can be downloaded from the Boost files section: http://groups.yahoo.com/group/boost/files/optional.zip Please state in review comments whether or not you believe that the library should be accepted into Boost. Further guidelines for writing reviews can be found here: http://www.boost.org/more/formal_review_process.htm#Comments Thank you, Doug Gregor (Optional (but not uninitialized) review manager)

1 0

Serialization Library Review
by David Abrahams 11 Nov '02

11 Nov '02

This is a belated announcement that the review period of Robert Ramey's Serialization Library, which runs from 9 November to 18 November, has started. Here is an introductory paragraph describing the library, from its documentation. In this system, we use term "serialization" to mean a system where the current state of group of objects can be stored to a permanent medium that may outlast the current program execution. At any later time an equivalent group of objects can be restored from the permanent medium. It is the goal of this system to permit this facility to be included in any C++ program with a minimium of additional effort. Here's a reminder of what to include in your review comments: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. You can download the library submission from http://groups.yahoo.com/group/boost/files/serialization6.zip -- David Abrahams dave(a)boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

1 0

Boost Version 1.29.0 released
by Beman Dawes 11 Oct '02

11 Oct '02

Boost Version 1.29.0 has been released. See www.boost.org. This is a major release, with five new libraries added and major revisions to several existing libraries: * Date-Time Library added - Dates, times, leap seconds, infinity, and more, from Jeff Garland. * Dynamic Bitset added - A runtime sized version of the std::bitset class from Jeremy Siek and Chuck Allison. * Format Library added - Type-safe 'printf-like' format operations, from Samuel Krempp. * Function Library: Major syntactic changes have been made. Some old syntax and little-used features have been deprecated (and will be removed shortly), and the syntax for the boost::function class template has been greatly improved on conforming compilers. Please see the compatibility note for more information. * Multi-array Library added - Multidimensional containers and adaptors for arrays of contiguous data, from Ron Garcia. * Preprocessor Library: Major upgrade, from Paul Mensonides. * Python Library - Version 2 is released, from Dave Abrahams and others. This is a major rewrite which works on many more compilers and platforms, with a completely new interface and lots of new features. Boost.Python v2 requires Python 2.2 or later. * Signals Library added - Managed signals & slots callback implementation, from Doug Gregor. * Test Library: Major new version, including full unit test capabilities, from Gennadiy Rozental. * uBLAS Library added - Basic linear algebra for dense, packed and sparse matrices, from Joerg Walter and Mathias Koch. --Beman

1 0

Formal Review: The Spirit Parser Framework
by Beman Dawes 11 Oct '02

11 Oct '02

The formal review for the Spirit Parser Framework begins today, and runs until the end of Sunday 20th October. Discussion should take place on the main boost developer list (boost(a)lists.boost.org) please state in your review whether you think the framework should be accepted into boost or not. The framework can be downloaded from: http://spirit.sourceforge.net/index.php?doc=download/v1_5.html Synopsis: ~~~~~~ Spirit is an object oriented recursive descent parser generator framework implemented using template meta-programming techniques. Expression templates allow us to approximate the syntax of Extended Backus Normal Form (EBNF) completely in C++. Parser objects are composed through operator overloading and the result is a backtracking LL(inf) parser that is capable of parsing rather ambiguous grammars. The Spirit framework enables a target grammar to be written exclusively in C++. Inline EBNF grammar specifications can mix freely with other C++ code and, thanks to the generative power of C++ templates, are immediately executable. In retrospect, conventional compiler-compilers or parser-generators have to perform an additional translation step from the source EBNF code to C or C++ code. Regards, John Maddock (Spirit review manager). http://ourworld.compuserve.com/homepages/john_maddock/index.htm

1 0

FileSystem Review Results
by William E. Kempf 04 Oct '02

04 Oct '02

From: "William E. Kempf" <williamkempf(a)hotmail.com> > The formal review of the FileSystem library is officially over. I'll > tabulate the votes and summarize the comments in the next day or two. > Thanks to all who reviewed the library. Sorry it's taken so long. My life is very hectic right now! I'd like to announce that the FileSystem Library has been accepted into Boost. We received several useful evaluations and obtained 7 votes, all for inclusion. Congratulations Beman! Here's a summary of the issues brought up during the review period: * Problems with the iterator implementations were pointed out and need corrected before official release. * Problems with the implementation when doing "Unicode builds" on Win32 platforms were pointed and need to be corrected before release. (Note this has to do with the Win32 API using macros to "transparently" select actual functions to be called based on whether or not Unicode is defined, and not to do with supporting Unicode file names.) * Path "joining" semantics were discussed and the syntax should be changed to "/" and "/=" (from "<<" and "<<="). * Issues with relative vs. absolute paths were discussed, and the general concensus was to add a "root" concept (overly simplified... refer to the reviews for full explanation). Moderators Note: This idea should actually make it relatively simple to add concepts such as URLs to the path concept, and is in general a very nice solution to a tricky portability issue. * An issue with filesystem/fstream when using VC6 was pointed out, and should probably be resolved (if possible) before official release. * Several people pointed out that file_path() and directory_path() were confusing. Beman suggests that these be moved to a sub-namespace since they should rarely be used. * It was suggested that the documentation for generic_path(), file_path(), directory_path(), leaf() and branch() need to be fleshed out some more. * Several people suggested there needs to be a method to query and manipulate the "current directory". Beman agrees but thinks the usage needs to be somehow discouraged. As review moderator I suggest that this functionality isn't strictly needed since the cases you'll need this are almost universally cases in which you'll be dealing with non-portable interfaces any way, so though inclusion is a worthy goal I don't think it should be required for the official release. * Extensions to allow for querying and manipulating attributes was suggested. This is another area where I think it's a worthy goal, but not necessary for official release of the library. * It was suggested that examples be given that implement cp, mv and ls, and code was even provided. This should be added to the official release. * There was some discussion about rename() being present, but no move(). As review moderator I'd like to point out that though a single method can be made to handle both concepts, on some platforms rename() semantics are restricted in several ways, such as not being able to rename() to an existing file name, not being able to rename across certain boundaries, such as file systems or even directories, etc. So if the choice is made to have only a single operation I'd suggest it be called move() instead, regardless of what the C Library may have done, as this obeys the principle of least surprise. In any event, I don't believe this issue is a sticking point and the group will accept any decision. * It was suggested that there's a need for more fine grained exception types. As moderator I'd suggest that most cases retain the current design, throwing only filesystem_error, while a few known cases be modified to throw exceptions derived from this type to more accurately signify what caused the error. As other cases become known we can change them to throw more fine grained exceptions as well. It's probably not worth the effort of trying to determine every possible case where finer grained exceptions *might* be needed at this point. * It was suggested that directory_iterator be made non-recursive by default, with an overloaded constructor to control this behavior. It's also noted that the predicate functionality of directory_iterator needs more documentation. * It was suggested that trailing "/" be allowed in paths, as on many platforms this would be expected behavior. * Several people think that i18n path name support is needed. I agree with Beman that this is a very complex issue that no one knows how to handle portably (and that it's not compatible with the standard libraries any way), so initially we should make sure the library is functional and feature complete before we tackle this issue. Hope I didn't miss any other important comments. Once again, congratulations Beman! Bill Kempf Review Moderator

1 0

Fwd: [boost] Filesystem Library: Formal Review
by William Kempf 15 Sep '02

15 Sep '02

>From: "William Kempf" <williamkempf(a)hotmail.com> >Reply-To: boost(a)lists.boost.org >To: boost(a)lists.boost.org, boost-announce(a)yahoogroups.com >Subject: [boost] Filesystem Library: Formal Review >Date: Sat, 14 Sep 2002 10:41:25 -0500 > >The formal review for the Filesystem Library starts today and ends Sept. >23. I'm the review manager, and Beman Dawes is the submitter. Guidelines >on forma reviews can be found at >http://www.boost.org/more/formal_review_process.htm. > >Here's a brief description of where to find the review files and other >pertinant information: > >>In preparation for the upcoming formal review of the Filesystem Library, >>final versions have been committed to the sandbox and the .zip file of the >>entire library has been refreshed at >>http://groups.yahoo.com/group/boost/files/filesystem/filesystem.zip >> >>Following the example of the Interval Library, the docs have also been >>uploaded to the files sections, so they can be browsed online without >>having to download anything. Start at >>http://groups.yahoo.com/group/boost/files/filesystem/index.htm >> >>Changes from the prior version: >> >>* Docs improved. >>* The directory_iterator implementation now uses >>boost::iterator_adaptor<>. >>* Deprecated path:: functions removed. >>* remove() function no longer throws on !exists(path). >> >>After long discussions of the last point on the list, I had promised to >>review the issue before the formal review. It is a tough call because >>there are no killer arguments either way. In the end, the slightly >>easier-to-use argument won over the slightly safer argument. >> >>AFAIK, the library should work with most compilers. It passes its tests >>for the usual Boost regression test Win32 compilers, John Maddock has used >>it on Linux, and Toon Knapen has used it on AIX. >> >>The remaining tasks are to flesh out the file and directory name >>portability checking functions and documentation, and port to the Mac. >>Those involve asking others to contribute work, so I don't want to do that >>until the library itself (hopefully!) passes formal review. > >Bill Kempf >williamkempf(a)hotmail.com > > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > >_______________________________________________ >Unsubscribe & other changes: >http://lists.boost.org/mailman/listinfo.cgi/boost Bill Kempf williamkempf(a)hotmail.com _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

1 0

Formal review results: Template Metaprogramming Library (MPL) accepted
by Douglas Gregor 29 Aug '02

29 Aug '02

Aleksey Gurtovoy's template metaprogramming library (MPL) has been accepted into Boost. Congratulations to Aleksey and thank you to the many reviewers. The vast majority of reviewers voted for acceptance; a summary of reviewer requests and comments is given below. [Design] * The iterator abstraction debate was never fully resolved. The iterator abstraction (that separates MPL algorithms from MPL containers via iterators, as in the STL) is central to the design of MPL. However, there is dissention regarding the necessity of this abstraction within the template metaprogramming domain, and the discussion persists because nobody has been able to identify a clear-cut example where a static data structure other than a simple typelist is required. The concensus here appears to be that MPL should not be delayed because of this question, but that additional experience with MPL will show whether the iterator abstract is useful or not. [Terminology] * Metafunction class vs. metafunctor vs. quoted Metafunction vs ...: Aleksey was counting votes on the naming of this entity. * select_if vs. if_ [Documentation] * Clarify the roles of the various placeholders (_ vs. _1, _2, etc.) * Incomplete reference documentation. Ron Garcia posted a list here (some of the items posted have since been documented): http://aspn.activestate.com/ASPN/Mail/Message/1288208 [Stability] * Interface changes in MPL left the MPL paper out of sync with the library (e.g., interface to iter_fold and several other algorithms). The MPL paper should be updated if it is to serve as an introduction to the library. [This may have already been resolved] * Ron Garcia also pointed to parts of MPL that are not tested by the testsuite. The list is here: http://aspn.activestate.com/ASPN/Mail/Message/1288208 * Some algorithms are broken for empty sequences (e.g., copy) [May already be resolved] * insert/insert_range broken [May already be resolved] * push_back for vector? [Requested Additions] * is_sequence has been requested to determine if a type T is a sequence [Eric Friedman] * an associative container (e.g., mpl::map) [Tom Wenisch] Thanks again to Aleksey and all of the reviewers, and my apologies for the delay in posting the review results. Doug Gregor gregod(a)cs.rpi.edu Review Manager, MPL

1 0

Dynamic Bitset formal review results
by Mat Marcus 18 Jun '02

18 Jun '02

The formal review period for the Dynamic Bitset library by Jeremy Siek and Chuck Alison is now complete. The review ran from June 8th through June 17th. After some improvements to the documentation the reviewers achieved consensus to accept the library. Actually, there was a single "no" vote, but it was without technical basis. Thanks to all the pople who took the time to participate in the review. Thanks also goes out to the authors, who responded efficiently to the major issues raised. I believe that the major technical comments/concerns were resolved by the authors during the review. Please speak up if I missed something. Remaining suggestions: The group strongly urges the a name change, with several people suggesting dynamic_bitset. Several people suggest removing the truth tables from the documentation. Future consideration: There were several requests for iterators, especially if the standard provides finer granularity iterators in the future. Thanks again to all involved. And thanks to Dave Abrahams for the fine Cuban cigars ;-) - Mat

1 0

Dynamic Bitset formal review - half way point
by Mat Marcus 14 Jun '02

14 Jun '02

Reminder - We have just past the half way point for the formal review of dynamic bitset. So far we have: 1 formal yes vote 1 formal no vote Discussion regarding iterators for dynamic bitset and comparison to vector<bool>. Some minor corrections and updates. I would like to see more formal reviews (including a yes or no vote) before the review period ends on the 17th. Thanks, Mat ##### > The formal review of Dynamic Bitset by Chuck Alison and > Jeremy Siek will commence today Saturday June 8th and run > through Monday, June 17th. > > The library is currently available at > <http://groups.yahoo.com/group/boost/files/dyn_bitset.tar.gz> > > > Below is an excerpt from the library's documentation: > > The dyn_bitset class represents a set of bits. It provides > accesses to the value of individual bits via an operator[] > and provides all of the bitwise operators that one can > apply to builtin integers, such as operator&& and > operator<<. The number of bits in the set is specified at > runtime via a parameter to the constructor of the > dyn_bitset. > > Each bit represents either the Boolean value true (set) or > false (reset). To toggle a bit is to change the value to > true if it is false and to false if it is true. Each bit > has a non-negative position pos. The position pos == 0 > corresponds to the least significant bit and pos == size() > - 1 is the most significant bit. When converting an > instance of dyn_bitset to or from an unsigned long, the > bit position pos corresponds to the bit value 1 << pos. > > The dyn_bitset class is nearly identical to the > std::bitset class. The difference is that the size of the > dyn_bitset (the number of bits) is specified at run-time > during the construction of a dyn_bitset object, whereas > the size of a std::bitset is specified at compile-time > through an integer template parameter. > > > For information about submitting a Formal Review, see > http://www.boost.org/more/formal_review_process.htm > > Please try out the library and comment during the review > period. Be sure to say whether or not you think the library > should be accepted by Boost. > > Compiler notes: This library has been tested using the > following compiler platforms: > > Gcc 2.95 and 3.01 > Kai C++ > Metrowerks Codewarrior 8 (beta, Mac) > Visual C++ 7.0 > Comeau > > The library presently requires template friend support and is > known not to compile with CodeWarrior 7.2 or Visual C++ 6.0. > > The library has not been tested with Borland. > > > The Formal Review manager is Mat Marcus. > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost-announce

1 0

Dynamic Bitset Formal Review June 8-17
by Mat Marcus 08 Jun '02

08 Jun '02

The formal review of Dynamic Bitset by Chuck Alison and Jeremy Siek will commence today Saturday June 8th and run through Monday, June 17th. The library is currently available at <http://groups.yahoo.com/group/boost/files/dyn_bitset.tar.gz> Below is an excerpt from the library's documentation: The dyn_bitset class represents a set of bits. It provides accesses to the value of individual bits via an operator[] and provides all of the bitwise operators that one can apply to builtin integers, such as operator&& and operator<<. The number of bits in the set is specified at runtime via a parameter to the constructor of the dyn_bitset. Each bit represents either the Boolean value true (set) or false (reset). To toggle a bit is to change the value to true if it is false and to false if it is true. Each bit has a non-negative position pos. The position pos == 0 corresponds to the least significant bit and pos == size() - 1 is the most significant bit. When converting an instance of dyn_bitset to or from an unsigned long, the bit position pos corresponds to the bit value 1 << pos. The dyn_bitset class is nearly identical to the std::bitset class. The difference is that the size of the dyn_bitset (the number of bits) is specified at run-time during the construction of a dyn_bitset object, whereas the size of a std::bitset is specified at compile-time through an integer template parameter. For information about submitting a Formal Review, see http://www.boost.org/more/formal_review_process.htm Please try out the library and comment during the review period. Be sure to say whether or not you think the library should be accepted by Boost. Compiler notes: This library has been tested using the following compiler platforms: Gcc 2.95 and 3.01 Kai C++ Metrowerks Codewarrior 8 (beta, Mac) Visual C++ 7.0 Comeau The library presently requires template friend support and is known not to compile with CodeWarrior 7.2 or Visual C++ 6.0. The library has not been tested with Borland. The Formal Review manager is Mat Marcus.

1 0