- Boost-announce - lists.boost.org

Numeric Conversion Formal Review
by Thorsten Ottosen 08 Dec '03

08 Dec '03

Dear all, The review of Fernando Cacciola Numeric Conversion library starts today (8th of Dec.) and runs until the 22th of December. >From the introduction: "The Boost Numeric Conversion library is a collection of tools to describe and perform conversions between values of different numeric types. The library includes a special alternative for a subset of std::numeric_limits<>, the bounds<> traits class, which provides a consistent way to obtain the boundary values for the range of a numeric type. It also includes a set of trait classes which describes the compile-time properties of a conversion from a source to a target numeric type. Both arithmetic and user-defined numeric types can be used." If you intend to make a review, then please read all of this mail. 1. The library can be downloaded in the files-section at yahoo (the file is called "numeric_conversions.zip") 2. Fernando and I are aware that the documentation could be more "tidy", but we don't think it will hinder any serious review. 3. Please try to work with Fernando if there arises compiler problems etc. Even of some compiler problems cannot be overcome, please try to focus on a useful subset of the functionality 4. Please follow the guidelines described at http://www.boost.org/more/formal_review_process.htm#Comments, in particular, remember to answer these (it makes it a lot easier to be a review manager) a.. What is your evaluation of the design? b.. What is your evaluation of the implementation? c.. What is your evaluation of the documentation? d.. What is your evaluation of the potential usefulness of the library? e.. Did you try to use the library? With what compiler? Did you have any problems? f.. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? g.. Are you knowledgeable about the problem domain? h.. 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. best regards Thorsten - review manager

1 0

String Algo Review Results
by Thorsten Ottosen 31 Oct '03

31 Oct '03

Dear All, The String Algorithm Library submission by Pavol Droba should be accepted into boost given that the issues that came up during the review are fixed. I know that my decision will please some and disapoint others, but I will try explain my decision later. I studied many former decisions made by review managers to see if I could find a pattaern of when to accept or reject a library. Rejection was done for these reasons: * too poor documentation * design does not meet enough user's needs * design was flawed When I summarize a decision on a certain issue, then I have read the whole thread, but sometimes the conclusion is not too easy to read from the discussion; so please say if you think I have made a mistake. Here's an overview of the rest of this mail: (1) Statistics (2) Critique of the library (3) Improvements that must be adressed before the inclusion of the library (1) Statistics -------------- Let my first show the statistics of this review: people doing a review: 7 people voting yes: 6 people voting no: 1 people with general comments: many In general it is understanding that most people payed most attention to the algortihms themselves; the traits, iterator_range, and find/formatter concepts and generating algorithms where not studied in detail. For future reference, I think it would be nice if people stated more explicitly what they tried and how long time they used on it. This is part of the checklist that I gave a link to in the mail that started the review. Many had wishes for extra algorithms and I think Pavol has them on his todo list. (2) Critique of the library -------------------------- In what follows I only discuss the major concerns during the review. (a) Two libraries are intertwined. On one side there a string algorithms and on the otherside support components for implementing these: container_traits, sequence_traits, iterator_range. This is indeed a relevant isssue that we must discuss. I think most agree that container_traits, sequence_traits and iterator_range (or half_open_range) should be a separate libraries. However, as long as the documentation clearly states that these sub-libs are just waiting for somebody to replace them, it shouldn't be any problem. On the contrary, the string library gives us a good starting point for evaluating the usefulness of these features, and I think we should thank Pavol for his courage to do this even though they might not be perfect yet. If we look at how other libraries evolve in boost, then they too change quite a bit as we get more experience with something. Examples like iterator_adaptors and regex come into mind. (b) Documentation is inadequate; imprecise. There was very different opinions on this. Some said the documentation was very good; others we're more pessimistic. Among those who actually did a review, most felt the docs where ok, but they did not mind more precise specifications and more examples. Some libraries have been rejected because of very poor documentation, but I don't think it would be fair to do it here. It counts that most reviewers were able to use the library without this extra documentation. The algorithms seems quite intuitive to use, and the docs wasn't really a show-stopper. Also, if we were to evaluate the documentation of other boost libraries just as harshly, they probably wouldn't make it into boost. Several other libraries are somewhat more demanding to use than the string algorithm library. (c) The library is more than a string library; ie. it will work with vector<foobar> even though it is not even close to a string. AFAICT, this is true for all functions not taking a locale parameter. When the review started, I mailed Craig Henderson because I know he has boyer more algorithms in the sandbox. Here is what he wrote: "WRT overlaps with my algorithms in the sequence_algo sandbox, I have already considered this, but concluded that the string algorithms are very specific to sequences of characters. The Boyer Moore, Edit Distance and LCS algorithms work on any sequence of data. I think they would loose flexibility and impact if I included them in the specific string algos." At that time I actually thought that Pavol's library was "merely" a generic string algorithm library. But in fact it is much more general than that: it searches and replaces and erases for subranges in a bigger range and strings are only one example of where this is handy. It's too early to say if this will cause changes to the Formatter/Finder concepts. I asked myself the question "is this reason enough for rejecting the library?". After some thought my answer was 'no' because 1) the algorithms that might be affected by this don't take a locale argument; the ones that do often have a similar name with an 'i' prefix. When and if the generic versions have their own library, the user should (mostly) be able to switch namespace and include a new header and everything works as before. 2) it doesn't hurt anyone that the implementation is a bit more general than it has to be 3) it will be easier to test if these function can actually be used as generic algorithms on their own How Craig's algorithms will fit into all this I cannot answer, but it should be dealt with during his review. (3) Improvements that must be adressed before the inclusion of the library -------------------------------------------------------------------------- Some of these changes are probably already incorporated by Pavol, but I'll mention them here for sake of completeness. If Pavol thinks that some of the points should be given a mini-review once again, he is free to do so on the list. It might be that some doc issues cannot be resolved before boost-book is updated; in that case there is not much to do but wait. (a) The documentation should have an overview table with all the libraries functions (b) implementation details should be better hided by using <i>Implementation defined</i> in docs (c) the namespace should be changed to boost::algorithm::string (d) it should be mentioned explicitly that traits and ranges are just temporary parts of the library and theit use should be discouraged. If there is no alternative under way, the docs could state that too. (e) concepts should be provided so it is clear what a string is or what type of containers that the algorithm works with (f) a general description about exception safety when using the library should be made (g) the header policy should changed so there is eg. only one find.hpp and not find.hpp and find2.hpp (h) grammar should be checked in docs (i) naming throughout the library should be made consistent; functions that take a predicate ends with _if; make_range should be renamed make_iterator_range or vice versa. (j) a safe-bool implicit conversion of the iterator range should be added (k) mutating algorithms should return void That's it folks! One thing that you might consider is critique of the review manager; should I have done something different? Earlier? etc. Don't be afraid to criticise me...the worst thing that can happen is that I might actually learn something. best regards Thorsten Ottosen, String Algo review manager

1 0

string algorithms review
by Thorsten Ottosen 18 Oct '03

18 Oct '03

The review of Pavol Droba's string algorithms library starts today and runs until the 30th of October. >From the introduction: "The String Algorithm Library provides a generic implementation of string-related algorithms which are missing in STL. It is an extension to the algorithms library of STL and it includes trimming, case conversion, predicates and find/replace functions. All of them come in different variants so it is easier to choose the best fit for a particular need. The implementation is not restricted to work with a particular container (like a std::basic_string), rather it is as generic as possible. This generalization is not compromising the performance since algorithms are using container specific features when it means a performance gain." When reviewing the library, please remember to go through this list: http://www.boost.org/more/formal_review_process.htm#Comments A part of the library interacts with the regular expressions (http://www.boost.org/libs/regex/index.htm) and requires one to build that first. The library has so far been tested with these compilers: a.. Microsoft Visual C++ 7.0 a.. Microsoft Visual C++ 7.1 a.. GCC 3.2 a.. GCC 3.3.1 Please refer to the portability section of the accompanying documentation for more information. If you try to review the library using a challenged compiler, please try to focus on the most useful subset of the library, that is, simply try if the library works with std::string; just having this functionality might be a great benefit for many users. If you have the time and know how to make something work on your compiler, please work with Pavol to solve those issues. If the change is very small, it might be appropriate to update the review source code; otherwise it will help Pavol's porting efforts when the time comes for a new release. The library and its documentation can be downloaded on the sandbox-webspace: http://boost-sandbox.sourceforge.net/string_algo.zip http://boost-sandbox.sourceforge.net/string_algo_doc.zip Please note that both zips should be unziped to a current cvs snapshot. best regards Thorsten - review manager

1 0

enable_if review
by Thomas Witt 07 Oct '03

07 Oct '03

The review of enable_if submitted Jaakko Järvi & Jeremiah Willcock & Andrew Lumsdaine starts today and runs through Sunday, October 12. From the introduction: "The enable_if family of templates is a set of tools to allow a function template or a class template specialization to include or exclude itself from a set of matching functions or specializations based on properties of its template arguments. For example, one can define function templates that are only enabled for, and thus only match, an arbitrary set of types defined by a traits class" This is going to be a fatstrack review. Fasttrack reviews have been introduced as a lightweight process in order to ease the acceptance of small utilities. I've put a more detailed description at the end of this message. When reviewing the library, please remember to include: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * Does the utility fit your needs as a library author/user And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? The implementation can be found in the boost-sandbox the respective files are: boost/utility/enable_if.hpp libs/utility/doc/enable_if.html libs/utility/test/enable_if* Archives can be found at the following location: http://www.osl.iu.edu/~jajarvi/tmp/enable_if.zip http://www.osl.iu.edu/~jajarvi/tmp/enable_if.tar.gz Furthermore the archives can be found in the yahoogroups file section under: enable_if/enable_if.zip enable_if/enable_if.tar.gz !!!!!!!!!!!!!! Only the sandbox version carries a boost compatible license. This is to avoid the repackaging effort. The final version will carry the boost license as the files in the sandbox do. So the license is a non-issue as far as this review goes. !!!!!!!!!!!!!! About Fasttrack Review ====================== What components qualify for a fasttrack review - --------------------------------------------- - The technique must be already in use in boost libraries thus the new component provides a common implementation - The component must be small Procedure - --------- - A full boost-conformant implementation is available in the sandbox - The Boost Review Wizard posts a review announcement to the list. Review period should last for 5 days. No two fasttrack review should run in parallel. Fasttrack reviews may run during full reviews, though generally this should be avoided. - After the review period ended, the submitter will post a review summary containing planned changes to the current implementation. - After applying all changes, the component will be checked in to cvs by the submitter. Thomas Boost Review Wizard

1 0

shifted_ptr review results
by Douglas Paul Gregor 02 Oct '03

02 Oct '03

The formal review period for Philippe A. Bouchard's shifted_ptr library has ended. At this time, the shifted_ptr library will not be accepted into Boost. The submission was rejected primarily on the grounds that its documentation was incomplete. Reviewers have requested complete semantic descriptions of shifted_ptr's operations, in addition to more rationale and introductory material. Reviewers also expressed concern with the potentially unsafe construction of shifted_ptr objects from a raw pointer; several solutions have been proposed. There is considerable interest in this library, and we hope that Philippe will address reviewers' concerns and bring this library forward for a second review in the future. Doug Gregor gregod(a)cs.rpi.edu Review manager, shifted_ptr

1 0

shifted_ptr review
by Douglas Gregor 24 Sep '03

24 Sep '03

The review of Philippe Bouchard's shifted_ptr library begins now and runs through Tuesday, September 30. Here is a short introduction to the library (from the documentation): "The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. This allows the use of reference counts with garbage collection. " When reviewing the library, please remember to include: * 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 here: http://groups.yahoo.com/group/boost/files/shifted_ptr.zip Thank you, Doug Gregor

1 0

Boost 1.30.2 is released
by David Abrahams 19 Aug '03

19 Aug '03

This release was managed by Dave Abrahams with the generous and dedicated help of Aleksey Gurtovoy and Misha Bergal of Meta-Communications, Inc., and of Martin Wille. We expect this to be the last release in the 1.30.x chain; see our CVS repository or its mirrors for new developments expected to appear shortly in 1.31.0. ------ release notes ------ August 19, 2003 - Version 1.30.2 (bugfix release) Boost Consulting is now hosting Boost CVS mirrors - see our download page. Backported changes to the config system, to better handle new compiler releases. Bugs in regression reporting in subproject tests were fixed. Tests are now run in the context of the user's PATH environment settings msvc-stlport and intel-win32-stlport toolsets now build static libraries with multithreading enabled, to be compatible with the STLPort builds. intel-win32 toolset now handles wchar_t correctly when intel is installed over msvc6. Backported fixes from the main trunk which prevent errors building the Boost.Test library in its default configuration. Backported portability improvements for checked_delete. Locale support for metrowerks (requiring a statically-linked runtime) is more uniformly handled. Backported conversion/lexical_cast's wchar_t fixes from the main trunk. intel-linux-tools: added rt to FINDLIBS in order to make the clock_gettime() function available (backport of a patch in CVS HEAD). regression/compiler_status.cpp: backported fixes in error log links generation. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost 1.30.1 released
by David Abrahams 04 Aug '03

04 Aug '03

Version 1.30.1 is a bugfix-only update. See http://www.boost.org for details of what has been fixed. Version 1.31.0, due out shortly, will contain some changes to library interfaces (notably the iterator adaptors library) which may break client code. Version 1.30.1 was released in order to deliver non-interface-breaking improvements to existing users of Boost 1.30.0. Note for Boost.Python users: this release is not compatible with Python 2.3. For information on how to obtain a Python 2.3-compatible version of Boost.Python, please see http://www.boost.org/libs/python. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Review Results: fixed-point decimal library
by Jens Maurer 23 Jul '03

23 Jul '03

The library has been reviewed by a number of boost contributors, including Paul Bristow, Ilya Buchkin, Fernando Cacciola, Daryle Walker and others. Thanks for your effort! Taking the review comments into considerations, the library will not be accepted into boost at its present state. Here's a short summary of what I believe are the most outstanding issues, but each review comment should be taken into account individually for a rework. - The documentation needs serious overhaul in both presentation and content. Words such as "precision" and "scale" should be defined, not all readers are experts in the domain. Specific technical requirements on the abstract type to be defined should be layed out ("financial applications" is not enough), and sound reasoning in the forest of alternatives should be provided. A comparison of the design to other programming languages or numerics standards is appreciated. Detailed semantics of each of the functions should be given, possibly similar in layout as the description of the standard library in the C++ standard. The discussion of the internal implementation should be moved to the very end to not distract readers from the interface. - The design should be reviewed. What happens with overflow? Financial people may want overflow signalled instead of silently eaten and producing wrong results. What happens with intermediate loss of precision? A number type is very surprising if its +,* operations are non-commutative. For a relatively simple value-based numerical type, inability to serve as a value type for STL containers is not acceptable. Providing a multitude of maths operators for various alien types such as int, double, and string instead of conversion or explicit constructors requires detailed reasoning to support the added complexity. On the positive side, boost::numeric has been agreed as the namespace for the library, and fixed_decimal appears to be a good name given the very interesting idea of standardized floating-point decimal numbers. Plus, the rounding control appears really ingenious syntax-wise. Nonetheless, thanks to Bill Seymour for bringing forward this library. Some boost readers wishing to code financial applications may now better understand the issues involved. Personally, I'm looking forward to a IEEE-conforming decimal floating-point library. Jens Maurer, Review Manager

1 0

Formal Review: fixed-point decimal library
by Jens Maurer 09 Jul '03

09 Jul '03

The formal review of Bill Seymour's fixed-point decimal library runs 11 July to 21 July 2003 with myself serving as review manager. The library provides a class boost::fixdec::decimal that represents a fixed-point number. Unlike "double" or other floating-point representations, a fixed-point number has a fixed number of decimal digits. Together with explicit rounding control, this prevents surprise from rounding errors, for example in financial applications. The library is available in the boost files section at http://groups.yahoo.com/group/boost/files/fixdecv22.zip The library has been successfully compiled on MSVC. (There should be an update shortly that allows compilation with como and gcc 3.3, presumably named fixdecv23.zip.) When submitting reviews, please state explicitly whether or not you think that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. Jens Maurer, Review Manager

1 0