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

Formal Review: Indexed Set
by Pavel Vozenilek 19 Mar '04

19 Mar '04

The review of Indexed Set library, written by Joaquín M López Muñoz starts today (March 20) and runs for 10 days. Latest version (9.4) of the library is available on: http://groups.yahoo.com/group/boost/files/indexed_set.zip (328 kB) What it is? indexed_set is generic, STL compliant container providing one or more views on its data. These views allow to use data sorted according to different criteria. Change in container data is automatically propagated into all views. How many views and what ordering is applied is specified in declarative way, as template parameter. What it is good for? - it can replace multiple collections of data and hand-written code keeping them in sync. - it can replace standard containers (as std::set or std::list) if these may not meet future reqirements. - it can serve as basic for other libraries. For example RTL (relational tables library) may use indexed_set to hold its data. Other features of indexed_set: - sorting can be performed on result of member function (similar to calculated indexes in RDBMS). - indexed_set can be used as 'wrapper' over other data structures, e.g you can see data in std::vector as being sorted in set-like structure (but without structures being synchronized). - many, many others ... Future development: - planned functionality is described on its own page in documentation. - indexed_set may also implement access to its data in the same way as std::deque, with random O(1) access History of the project: - it started as 'bimap' library more than year ago, - some two dozen iterations were released, - several Boost people expressed their interest or did suggest features. Boost-wide reusable parts of the library: - indexed_set includes (nearly verbatim) copy of Andrei Alexandresu ScopeGuard. It is intended as stop-gap until Boost wide library emerges. - maybe auto_space.hpp can be liften into utilities. Portability: - see document page for list of compilers and their issues - Can someone try to run tests under release mode of VC 6.5? We got different results with different machines. Word from the autor: "Thank you for reviewing indexed_set. There are several points, mostly concerning naming, that I'd like to be discussed during the review. You can find these at the URL http://groups.yahoo.com/group/boost/files/indexed_set_review_notes.html If you evaluate the library and deem it acceptable for Boost, please walk the extra mile and express your opinions about the issues brought forward in the review notes. Naming issues are quite sensitive, and I'd like to reach as general a consensus as possible." Your review comments are welcomed. Found problems and suggestions for documentation are highly sought. Requests for new features requests may shape way indexed_set will evolve in future. As naming questions can generate lot of mail-list traffic, I'll start separate thread to deal with them. /Pavel

1 0

Formal Review: Circular Buffer
by Pavel Vozenilek 05 Mar '04

05 Mar '04

The review of Jan Gaspar's Circular Buffer library starts today (March 5th) and runs for 10 days. Latest version of the library is available at: http://groups.yahoo.com/group/boost/files/circular_buffer_v3.6.zip What it is: Circular buffer (also known as ring or cyclic buffer) is container with fixed upper limit on number of elements inside. When capacity gets exhausted newly inserted elements will cause oldest elements to get dropped out. What makes the library Boost candidate: - it provides often used functionality, - it is STL compliant generic solution, - it is designed for CPU/memory efficiency, - it is fully documented and tested, - it contains extensive debug support, - it has been informally reviewed for long time. Discovered problems in code or in documentation, missing features, portability issues and finally opinion whether the library belongs to Boost is welcomed. /Pavel

1 0

FC++ Formal review is now in progress (2/13-2/23)
by Mat Marcus 13 Feb '04

13 Feb '04

The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, runiing from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

1 0

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

09 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 PS: Sorry if this is a duplicate. Several people have reported they never got the original announcement.

1 0

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