- Boost-announce - lists.preview.boost.org

Formal Review for Boost I/O Library
by Ed Brey 27 Feb '03

27 Feb '03

The formal review for the updated Boost I/O Library begins today and runs through March 7. The I/O library contains various components for use with the standard I/O library. The components are as follows: State-saving classes for various IOStream attributes. Class templates to ease making streams off a new stream-buffer class. Stream and stream-buffer class (templates) that use an internal array. Additional I/O manipulator function (templates). The stream buffer classes are new and deserve primary attention in this review. You can obtain the latest version of the library from the CVS sandbox. For web access to the library, use this URLs: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/… http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/… Please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments Thanks, Ed (Review Manager)

1 0

Formal Review: Variant Library
by Jeff Garland 17 Feb '03

17 Feb '03

All - Today is the start of the formal review of the Variant library by Eric Friedman and Itay Maman. The review will run until Tuesday Feb. 25th. I will be serving as review manager. The variant library offers a simple, type-safe solution for manipulating an object from an inhomogeneous set of types in a uniform manner. Whereas standard containers such as std::vector may be thought of as "multi-value, single type," variant is "multi-type, single value." This reduces code duplication and enhances maintainability. You can obtain the latest version of the library from the boost-sandbox or from: http://groups.yahoo.com/group/boost/files/variant.zip Please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments Thanks, Jeff

1 0

Review results: Optional library
by Douglas Gregor 06 Jan '03

06 Jan '03

Fernando Cacciola's Optional library is accepted into Boost. The review process was complicated by continual revision of the Optional library, and for this reason at least one reviewer favored rejection of the library at this time. However, the author and reviewers were quick to respond to interface revisions and were able to settle on a final interface, so the complications arising from interface fluctuations did not appear serious enough to override the majority of reviewers favoring acceptance. Doug Gregor Review Manager, Optional library

1 0

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