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

Boost release 1.31.0 is available
by Beman Dawes 05 Feb '04

05 Feb '04

Boost release 1.31.0 is available. See the www.boost.org home page for latest news about what's in the release. Or go right to http://sourceforge.net/project/showfiles.php?group_id=7586 to download. Thanks to everyone who helped with this release. The folks that run the regression tests and review the release candidates get a special pat on the back. Due to compiler updates, three shipping and one soon-to-ship C++ compiler now pass almost all of Boost's regression tests. A year ago, no compilers could do that. --Beman

1 0

Mail Delivery System
by wekempf＠cox.net 05 Feb '04

05 Feb '04

1 0

HI
by jens.maurer＠gmx.net 02 Feb '04

02 Feb '04

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.

1 0

Numeric Conversion Review Results
by Thorsten Ottosen 29 Dec '03

29 Dec '03

Dear All, I'm pleased to announce that Fernando Cacciola's Numeric Conversion library is accepted into boost. Although it was not clear how all advanced issues should be resolved (see below), I think there is a solid foundation on which to improve the library. Bjarne Stroupstrup has said that good languages are not merely designed to be good, but they are grown into good languages; IMO, the same holds for libraries. The rest of this mail has this agenda: 1) statistics 2) issues 3) improvements that must be made (1) Statistics -------------------- Here is how people voted: people doing a review: 9 people voting yes: 7 people voting no: 0 people not voting: 2 Some general comments: Only one person was *really* knowlegable about the floating point numbers; the rest of us did our best to try to understand. Luckily the most simple part of the library was fairly easily evaluated. As for the more advanced part, it seemed to me that many had too little time to do a thoughrough review (myself included) and it was a bit hard to come up with a test program where all of the lib could be tested. (2) Issues: ---------------- Below are some of the most important issues that came up during the review. a) Float to int conversions incremented the integer value. Fernando thinks it can be healed with a custom specialization of the rounder policies for these types. b) The library should be put in its own directory. c) Improved UDT support (if it is necessary). There are several physical quantity libs being built and it remains to be seen if those people can use it. d) Long to float conversion: Consider Andy Little's example: int main() { long x = std::numeric_limits<long>::max(); std::cout.precision(16); std::cout << x <<'\n'; float y = x; std::cout << y << '\n'; x = y; std::cout << x <<'\n'; } /* output from test.exe: 2147483647 2147483648 -2147483648 */ Fernando agued that this should not be checked by his library. The documentation should definitely document what conversion it cannot be used to convert. (3) improvements that must be made -------------------------------------- (a) more and enhanced documentation. There was a lot of people requesting more examples, relations between different parts of the library. And a getting started guide would be good too. Maybe the easy parts should be cleanly separated from the more advanced parts. A consistent use of fonts for math, code, emphasis, definitions is needed. Fernando should seek the authors of the existing numeric_cast documentation permission to reuse some of their documentation. In general there was no huge design decision that was being deemed unacceptable. Thanks to everybody who took part of the review. best regards Thorsten -- review manager

1 0

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