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

Review Wizard Status Report for June 2009
by Ronald Garcia 02 Jun '09

02 Jun '09

============================================== Review Wizard Status Report for June 2009 ============================================== News ==== Futures: Williams variant Accepted; Gaskill variant Rejected Boost 1.38 Released New Libraries: Revised Libraries: Boost.Range Extension Accepted Polynomial Library Rejected Boost 1.39 Released Constrained Value Review - Review Result Pending Older Issues ============ The Time Series Library, accepted in August 2007, has not yet been submitted to SVN. Eric Niebler and John Phillips are working on making the changes suggested during the review. The Floating Point Utilities Library, has not yet been submitted to SVN. It is slated to be integrated with the Boost.Math library. The Switch Library, accepted provisionally in January 2008, has not yet been submitted for mini-review and full acceptance. The Phoenix Library, accepted provisionally in September 2008, has not yet been submitted for mini-review and full acceptance. A rewrite of Phoenix, basing it on the Proto metaprogramming library, has just begun. General Announcements ===================== As always, we need experienced review managers. The review queue has been growing substantially but we have had few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. A recent effort is trying to secure at least five people who promise to submit reviews as a precondition to starting the review period. Consider volunteering for this and even taking the time to create the review as early as possible. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Lexer * Shifted Pointer * Logging * Log * Join * Pimpl * Thread Pool * Endian * Meta State Machine * Conversion * Sorting * GIL.IO * AutoBuffer * String Convert -------------------- Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Vault <http://boost-consulting.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Vault <http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… >`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. 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. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Log --- :Author: Andrey Semashev :Review Manager: Needed :Download: `Boost Vault <http://tinyurl.com/cm9lum>`__ :Description: The library is aimed to help adding logging features to applications. It provides out-of-box support for many widely used capabilities, such as formatting and filtering based on attributes, sending logs to a syslog server or to Windows Event Log, or simply storing logs into files. It also provides basic support for the library initialization from a settings file. The library can also be used for a wider range of tasks and implement gathering and processing statistical information or notifying user about application events. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… >`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Thread Pool ----------- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: The library provides: - thread creation policies: determines the management of worker threads: - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks: - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited number of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel: - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> ``this_thread::interruption_point()`` ). Endian ------ :Author: Beman Dawes :Review Manager: Needed :Download: http://mysite.verizon.net/beman/endian-0.10.zip :Description: Header boost/integer/endian.hpp provides integer-like byte-holder binary types with explicit control over byte order, value type, size, and alignment. Typedefs provide easy-to-use names for common configurations. These types provide portable byte-holders for integer data, independent of particular computer architectures. Use cases almost always involve I/O, either via files or network connections. Although data portability is the primary motivation, these integer byte- holders may also be used to reduce memory use, file size, or network activity since they provide binary integer sizes not otherwise available. Meta State Machine ------------------ :Author: Christophe Henry :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?direction=0&order=&director… >`__ :Description: Msm is a framework which enables you to build a Finite State Machine in a straightforward, descriptive and easy-to-use manner . It requires minimal effort to generate a working program from an UML state machine diagram. This work was inspired by the state machine described in the book of David Abrahams and Aleksey Gurtovoy "C++ Template Metaprogramming" and adds most of what UML Designers are expecting from an UML State Machine framework: * Entry and Exit Methods * Guard Conditions * Sub state machines (also called composite states in UML) * History * Terminate Pseudo-State * Deferred Events * Orthogonal zones * Explicit entry into sub state machine states * Fork * Entry / Exit pseudo states * Conflicting transitions Conversion ---------- :Author: Vicente Botet :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co… >`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al… >`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 8X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 7X as fast as std::sort on x86 processors. string_sort is roughly 2X as fast as std::sort. GIL.IO ------ :Author: Christian Henning :Review Manager: Needed :Download: `GIL Google Code Vault <http://gil-contributions.googlecode.com/files/rc2.zip >`__ :Description: I/O extension for ``boost::gil`` which allows reading and writing of/in various image formats ( tiff, jpeg, png, etc ). This review will also include the Toolbox extension which adds some common functionality to gil, such as new color spaces, algorithms, etc. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Needed :Download: `Here <http://www.cs.aau.dk/~nesotto/boost/ auto_buffer.zip>`__ :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. String Convert -------------- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: The library takes the approach of boost::lexical_cast in the area of string-to-type and type-to-string conversions, builds on the past boost::lexical_cast experience and advances that conversion functionality further to additionally provide: * throwing and non-throwing conversion-failure behavior; * support for the default value to be returned when conversion fails; * two types of the conversion-failure check -- basic and better/safe; * formatting support based on the standard I/O Streams and the standard (or user-defined) I/O Stream-based manipulators (like std::hex, std::scientific, etc.); * locale support; * support for boost::range-compliant char and wchar_t-based string containers; * no DefaultConstructibility requirement for the Target type; * consistent framework to uniformly incorporate any type-to-type conversions. It is an essential tool with applications making extensive use of configuration files or having to process/prepare considerable amounts of data in, say, XML, etc. Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review. Mirror ------ :Author: Matus Chochlik :Download: | http://svn.boost.org/svn/boost/sandbox/mirror/doc/index.html | `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=mi… >`__ :Description: The aim of the Mirror library is to provide useful meta-data at both compile-time and run-time about common C++ constructs like namespaces, types, typedef-ined types, classes and their base classes and member attributes, instances, etc. and to provide generic interfaces for their introspection. Mirror is designed with the principle of stratification in mind and tries to be as less intrusive as possible. New or existing classes do not need to be designed to directly support Mirror and no Mirror related code is necessary in the class' definition, as far as some general guidelines are followed Most important features of the Mirror library that are currently implemented include: * Namespace-name inspection. * Inspection of the whole scope in which a namespace is defined * Type-name querying, with the support for typedef-ined typenames and typenames of derived types like pointers, references, cv-qualified types, arrays, functions and template names. Names with or without nested-name-specifiers can be queried. * Inspection of the scope in which a type has been defined * Uniform and generic inspection of class' base classes. One can inspect traits of the base classes for example their types, whether they are inherited virtually or not and the access specifier (private, protected, public). * Uniform and generic inspection of class' member attributes. At compile-time the count of class' attributes and their types, storage class specifiers (static, mutable) and some other traits can be queried. At run-time one can uniformly query the names and/or values (when given an instance of the reflected class) of the member attributes and sequentially execute a custom functor on every attribute of a class. * Traversals of a class' (or generally type's) structure with user defined visitors, which are optionally working on an provided instance of the type or just on it's structure without any run-time data. These visitors are guided by Mirror through the structure of the class and optionally provided with contextual information about the current position in the traversal. I'm hoping to have it review ready in the next few months. Interval Template Library ------------------------- :Author: Joachim Faulhaber :Description: The Interval Template Library (Itl) provides intervals and two kinds of interval containers: Interval_sets and interval_maps. Interval_sets and maps can be used just as sets or maps of elements. Yet they are much more space and time efficient when the elements occur in contiguous chunks: intervals. This is obviously the case in many problem domains, particularly in fields that deal with problems related to date and time. Interval containers allow for intersection with interval_sets to work with segmentation. For instance you might want to intersect an interval container with a grid of months and then iterate over those months. Finally interval_maps provide aggregation on associated values, if added intervals overlap with intervals that are stored in the interval_map. This feature is called aggregate on overlap. It is shown by example: :: typedef set<string> guests; interval_map<time, guests> party; guests mary; mary.insert("Mary"); guests harry; harry.insert("Harry"); party += make_pair(interval<time>::rightopen(20:00, 22:00),mary); party += make_pair(interval<time>::rightopen_(21:00, 23:00),harry); // party now contains [20:00, 21:00)->{"Mary"} [21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap [22:00, 23:00)->{"Harry"} As can be seen from the example an interval_map has both a decompositional behavior (on the time dimension) as well as a accumulative one (on the associated values). StlConstantTimeSize ------------------- :Author: Vicente J. Botet Escriba :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=consta… >`__ :Description: Boost.StlConstantTimeSize Defines a wrapper to the stl container list giving the user the chioice for the complexity of the size function: linear time, constant time or quasi-constant. In future versions the library could include a similar wrapper to slist. InterThreads ------------------- :Author: Vicente J. Botet Escriba :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=in… >`__ :Description: Boost.InterThreads extends Boost.Threads adding some features: * thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit. * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. * thread tuple: defines a thread groupe where the number of threads is know statically and the threads are created at construction time. * set_once: a synchonizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. (thread_decorator and thread_specific_shared_ptr) are based on the original implementation of threadalert written by Roland Schwarz. Boost.InterThreads extends Boost.Threads adding thread setup/cleanup decorator, thread specific shared pointer, thread keep alive mechanism and thread tuples.

1 0

[ANN] Boost 1.39.0
by Beman Dawes 02 May '09

02 May '09

Boost 1.39.0 is available for download from SourceForge. See http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&… New Libraries: Signals2. Updated Libraries: Asio, Flyweight, Foreach, Hash, Interprocess, Intrusive, Program.Options, Proto, PtrContainer, Range, Unordered, Xpressive. Updated Tools: Boostbook, Quickbook. Plus the usual bug fixes to numerous libraries. Please report any problems to the Boost users or developers mailing list. Thanks, --Beman Dawes, Daniel James, and all the other Boosters who help get releases out

1 0

[Review Results] Range.Ex library accepted into boost
by Thorsten Ottosen 27 Apr '09

27 Apr '09

Dear all, It is my pleasure that Neil Groves' RangeEx library has been accepted into boost. Congratulations Neil! There are quite a number of minor issues that need to be resolved before the library is release ready, see below for a summary. Review statistics ----------------- Full Reviews: 8. Discussion: extensive. I had the clear impression that everybody that participated in the discussion were in favor of this library, albeit they did not have time to submit a full review. I did not hear a single statement saying that this library should be rejected. Thanks to everybody that participated in the review and its discussions. Issue Summary ------------- Below is given a list of topics that must be adressed before the library can be included into boost. In general, we should try to discuss them one at a time in seperate threads. Many people suggested various extensions, new algorithms (e.g. from adope), etc. **In general we should not require Neil to add all these if he does not have the time currently: the basic infrastructure, the concepts, the naming and organization of the library is much more important. Then we can add all these things later.** 1: documentaion =============== The documentation should clearly reflect if an algorithm delegates to a standard algorithm. If the algorithm is new, then it should state complety and exception-safety. More examples would be welcome. Sometimes the rationale and explanations could be improved, e.g for operator|(). 2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.) boost::find[_f,_e]( range, x ) boost::find[_f+1,_e]( range, x ) was considered good by most. 3: namespace organization ========================= Currently the library uses the namspaces boost boost::adaptors Some raised concern about putting the algorithms straight in the boost namespace before we have a general agreement on where to put algorithms (e.g. in boost::algorithm or boost::ranges or whatever). I think it will make sense to put each algorithm in its own header, since we might have to include additional standard library headers for calling algorithms that are implemented as member functions (but see 7 below). Feedback is most welcome. 4: naming convention for adaptors ================================= The following have been proposed throughout the review (here examplified with "transform"): | transformed( fun ) | transform( fun ) | transform_view( fun ) | view::transform( fun ) There where no consensus during the review. Other libraries seem to use the _view suffix, which is a strong argument for that candidate (in that case, I suggest to drop the adaptors namespace). 5: naming convention for the adaptor generators =============================================== Many people like to be able to say make_transform_range(r,fun) instead of r | transformed( fun ). There was no concensus on how to name these functions. Here are some candidates: make_transform_range( r, fun ) transformed( r, fun ) transform( r, fun ) (*) transform_view( r, fun ) (*) was dislike by some because it has exactly the same spelling as the algorithm transform. Many felt that the confusion is too big if view generators are not named different from the actual algorithms. 6: reintroducing _if variants of algorithms =========================================== An important problem with the suggested approach was the the iterator returned by an algorithm after applying | filtered( pref ) are now filtered iterators and so one needs to manually unwrap the return iterator. This provided enough justification for reintroducing these algorithms. (One could imagine that this unwrapping was done automatically by a conversion operator such that iterator i = boost::find( r | boost::filtered( pred ), x ); "just worked". However, the syntax is still slightly worse than just using the original algorithm). Generic programming is concerned with the use of orthogonal concepts which put together yields all possible combinations of algorithms. If we reintroduce all _if algorithms, we have to aks ourselves "when does it end?". Should all new algorithms then simply add _if variants? This seems very much against the spirit of generic programming. The problem with the iterators being changed (as in the find example) seems to suggest the following guideline: "If the algorithm returns an iterator, it makes sense to provide an _if overload. Otherwise it does not." Under this guideline, find_if() should be there, but count_if() should not be provided. 7: should algorithms call member function when possible? ======================================================== I heard one strong voice against this. The reason was that the algorithm implemented as member function often has quite different guarantees w.r.t. complexity, reference and iterator stabililty. I think this is a very strong argument. Also, we can add this later if good arguments appear, but it is much harder to take away. We also have to remember Scott Meyers item "Beware of container independent code" which also suggest that this is a bad idea. At the very menimum, the original algorithm and the member function should have similar semantics. This seems to suggest that we can call set::lower_bound() from boost::lower_bound(). In that case, the best way would probably be to add these as overloads in the boost namespace: template< class T, class A > typename std::set<T,A>::iterator lower_bound( std::set<T,A>& s ); template< class T, class A > typename std::set<T,A>::const_iterator lower_bound( const std::set<T,A>& s ); 8: making return values of algorithms consistent/intuitive ========================================================== For example, sort(r) returns the sorted range, but sort_heap(r) does not. Similar issues for partial_sort(). Please go through all algorithms to see if this done correctly. 9: output range concept? ========================= It appears that the only use for an output iterator in the library was for boost::copy(rng,iter), and the only use for that function was for "sinks" like std::ostream_iterator<T>(...). This seems to be the only safety hole left in the library. Here's an idea to how we might remove that: create a new "copy sink" concept: struct array_copy_sink { ... template< class Iterator > copy( Iterator begin, Iterator end ) { ... } }; Then we might imagine boost::copy( rng, boost::ostream_sink(std::cout) ); boost::copy( rng, boost::array_sink(an_array) ); boost::copy( rng, boost::ptr_sink(begin,end) ); boost::copy( rng, boost::front_insert_sink(a_deque) ); ... For optimal performance, we also need a "nonoverlapping copy sink" concept, and an algorithm that expects that sink (or that boost::copy() determines the type of the sink automatically). 10: automatic projection ======================= Adope has algorithms overloaded such that projection is very easy: struct my_type { int member; double another_member; }; //... my_type a[] = { { 1, 2.5 }, ... }; // sort the array by the first member: sort(a, less(), &my_type::member); my_type* i = lower_bound(a, 5, less(), &my_type::member); We should be able to express this well, albeit not as concise, with my_type* i = boost::lower_bound( a | project( &my_type::member ), 5, less() ); where project( ... ) could simply return a transform iterator constructed with boost::bind(). There is another problem, however, because now the return value is a tranform_iterator of some form. Appending .base() would solve it, albeit it is somewhat ugly. Again this might raise the question of an implicit conversion. I just want to say this is not a critical issue as we can always add these overloads. --- End of Issues ---- Again, I would like to thank everybody that participated in the review. best regards Thorsten, review manager

1 0

Boost 1.39.0 beta 1 is available for download
by Beman Dawes 26 Apr '09

26 Apr '09

Boost 1.39.0 beta 1 is available for download from SourceForge. See http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&… New Libraries: Signals2. Updated Libraries: Asio, Flyweight, Foreach, Hash, Interprocess, Intrusive, Program.Options, Proto, PtrContainer, Range, Unordered, Xpressive. Updated Tools: Boostbook, Quickbook. Plus the usual bug fixes to numerous libraries. Please report any problems to the Boost users or developers mailing list. Thanks, --Beman Dawes, Daniel James, and all the other Boosters who help get releases out

1 0

Review Conclusion - Futures Library
by Tom Brinkman 21 Apr '09

21 Apr '09

Review Conclusion - Futures Library Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp The lack of examples and documentation made them difficult to review. Nevertheless, Anthony Williams futures library did receive almost unanimous and enthusiastic support. Unfortunately, the depth of the support was very shallow. I just finished my first read of Anthony's book "C++ Concurrency in Action and acknowledge his expertise in the areas of multi threaded and parallel programming. (http://www.manning.com/williams/) Anthony is the maintainer of boost::threads. Anthony's Future library has been approved for the next major release of c++ standard. Conclusion Braddock Gaskill - Rejected Anthony Williams - Approved Anthony's Futures library is approved for inclusion into boost::threads. As he is the maintainer of that library, he should be given maximum latitude about how that is to be done. In the future, if Anthony wants to re-publish the library as a top-level boost library, then he needs to resubmit it again with samples and test cases, which are lacking. Requirements As per the usual boost library requirements, examples and test cases are needed. Anthony should also improve the documentation, which should not be a problem as he is a prolific author in the area of multi threaded programming. Review Manager Tom Brinkman

1 0

[boost] [Polynomial] Review Result
by John Maddock 09 Apr '09

09 Apr '09

Apologies for the delay in putting this together... First off I'd like to thank the author for submitting this for review - I wish all our SOC students were similarly diligent! :-) We received a number of reviews of this library, but none were in favor of acceptance in its current form, and most thought that there was still a fair bit of work to do to get the library into shape. However, most thought that the library could be accepted into Boost given sufficient changes/enhancements. Therefore the library is not accepted into Boost at this time, but I would like to encourage the author to continue to work on the library and resubmit at a future time. In no particular order the main review comments are summarized below: Principal comments: * Documentation, especially the background is inadequate and needs a good proofreading a) From the examples are nothing that a competent programmer couldn't figure out from the declarations. Some more interesting or useful examples would be nice, particularly for things like the special forms. It's not exactly clear what I would do with those functions. b) There is no documentation or references to the various algorithms used. Those, too, would be nice. c) Doc.html appear to have been created 'the Hard Way'. Would be much more useful and look nicer if produced with the Quickbook, Doxygen... toolchain. And make it maintainable by other people. * Use of constructors and assignment operators that modify their arguments isn't acceptable - best to find another interface for this. * Several reviewers noted that the code didn't build for them, in particular log2 isn't available on all platforms/compilers. * evaluate_polynomial() and evaluate_polynomial_faithfully() take their coefficient arguments in the opposite order of all the other functions/constructors in the library, without providing any reason for that choice. That's seems somewhat surprising. I'd suggest fixing that, or at the very least providing an argument in the documentation why this makes some sense. * Rename evaluate() to horner() and provide evaluate() as an inline call to horner(). * Rename evaluate_faithfully() to compensated_horner(). * Things that say "Be careful about this" generally need fixing. * It would be nice to have operator* and operator/ as well as *= and /=. * Considering they share the same core algorithm, it might be nice to have a function that could do division and return the remainder at the same time. Something like poly::divide(P &divisor, P &quotient, P &remainer) * FFTs are good for multiplying polynomials above a certain size, but they are rather heavy for small polynomials and can lead to unexpected crosstalk between terms. There should be an option for * that doesn't use the FFT, and it should be the default for small polynomials. * operator/= has a hardcoded "std::vector<double> new_coefficients" that later gets rounded?? This should be fixed to work with any type that fulfills the necessary conceptual requirements (and tested and documented what those requirements are - it would be nice if they were the same as the rest of Boost.Math). * The name FieldType is mathematically misleading since the instantiating type is very likely not to be a field (e.g. int or a multiple precision integer type). * the Polynomial class provides a fairly minimalist set of supported functions. This may well be deliberate (if so, apologies), but I would like to see a richer interface including such things as - content (gcd of coefficients, where that makes sense) - polynomial discriminant - resultant of 2 polynomials - evaluation of homogeneous polynomial ( f(x) = sum c_i x^i,f(a,b) = sum c_i a^i b^(d-i) ) - evaluation at a polynomial (f(g(x))) - Pseudo-division of polynomials - finding roots over C - finding roots over F_p - factorisation over Z - factorisation over F_p * We had one feature request for extending support to finite fields. * This constructor: template<typename U> polynomial(const U& v); had me a little confused at first - is there any advantage to making this a template rather than simply accepting a const FieldType& as the single argument? * It's not clear from the documentation what this constructor does: polynomial(InputIterator first1, InputIterator last1, InputIterator first2); It needs to clearly state the degree of the resulting polynomial and whether it passes through all/any of the points - in fact maybe the constructor should have a final parameter for the degree of the polynomial and use least-squares fitting when required? Likewise for the member function template<typename InputIterator> void interpolate(InputIterator first1, InputIterator last1, InputIterator first2); * Operators: the / and % operators need good descriptions of what they do, given that no exact division is possible. As someone else has already noted, a function to calculate divide and remainder in one step would be useful too. * GCD: presumably this is restricted to polynomials with integer coefficients? If so it should say so. * Evaluation: The docs should say what method is used for the evaluate_faithfully method and give a reference. Renaming as someone else suggested may be better too, but personally I'm easy either way on that. I'm not sure whether there should be an evaluate_by_preconditioning method, shouldn't the polynomial "know" that it has been preconditioned and react accordingly. I haven't looked/checked but do the usual arithmetic operators still work if the polynomial has been preconditioned? I assume probably not, but if that's the case there should be a stern warning to that effect, *and* checks in code to prevent us from doing something stupid :-) BTW, preconditioning can be applied to polynomials of any degree I believe it's just that it gets hard to implement in the generic case. In addition I'd like to see the evaluation functions templated, so that the type being evaluated can differ from FieldType - it would surely be quite common for example to create and manipulate polynomials with integer coefficients, but then want to evaluate on a floating point type. There is machinery in Boost.Math BTW to handle the mixed argument-promotion and calculation of the result type, let me know if you need help in using this. * Special Forms: the functions provided do *not* generate polynomials in the alternative forms, but rather generate the named polynomial of order N, which is rather less useful, but at the very least the docs need updating to reflect this. * test_arithmetics.cpp fails on cygwin: or at least it did once I added a using std::pow; to start of operator*= to get things compiling. * None of the code builds with msvc: there are a couple of issues here: friend polynomial<FieldType> boost::math::tools::gcd<>(polynomial<FieldType> u, polynomial<FieldType> v); Needs to be changed to: friend polynomial<FieldType> boost::math::tools::gcd<FieldType>(polynomial<FieldType> u, polynomial<FieldType> v); to get msvc to Grok the code. After that there are a bunch of failures due to the use of log2 which msvc doesn't support (and since it's not part of the std other compilers are likely to complain too). * I haven't looked too hard at the implementation, except to echo the comments posted previously that the Conceptual requirements for FieldType need documenting and *testing*. There are concept checking classes and archetypes in Boost.Math which may be of use here. Again, shout if you need help in figuring out how to use these. I did notice that operator*= for example uses std::complex<double> internally which effectively limits the precision that can be achieved - to be useful to me - and to replace the existing "implementation detail" polynomial class in Boost.Math - I would need the polynomial class to be usable with arbitrary precision types such as NTL::RR or mpfr_class. Also as previously noted, multiplication of small polynomials may well be more efficient with the "naive" algorithm, so some performance tests and experimenting is required here. Related to this, use of "round" should be restricted to types that are known to be integers? Regards, John Maddock Review Manager for Polynomial Library. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

BoostCon 2009 Schedule Now Live
by David Abrahams 24 Mar '09

24 Mar '09

The official schedule is now live at http://www.boostcon.com/program! A few highlights of the "mouth-watering content" (in the words of one enrollee) are: * A keynote address from Andrei Alexandrescu called "Iterators Must Go." It's sure to be provocative! * Troy Straszheim's presentations on how high-energy physicists are using Boost to process massive datasets as they go "Icefishing for Neutrinos" and on Kamasu, his library for offloading computation to your machine's GPU. * Two hands-on sessions where we'll start recoding parts of Boost for C++0x, applying rvalue references, variadic templates, decltype, and advanced SFINAE capabilities using the latest GCC. * "Practical C++ Test-Driven Development with Boost.Test and Bmock," by Asher Sterkin * A session on compiler construction using Boost.Spirit v2, from Hartmut Kaiser and Joel de Guzman The complete list of sessions covers a wide range of other Boost and C++-related topics. It is available at http://www.boostcon.com/program/sessions. Please have a look, and please, sign up for the conference! Remember, registration for the whole week is just $599 before April 1st. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[boost] [Review] Polynomial library review begins today
by John Maddock 10 Mar '09

10 Mar '09

The review of Pawel Kieliszczyk's Polynomial library begins today and ends on Thurs 19th March. Download of the zip file from the vault is here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=polyno… Otherwise the library is present in the sandbox here: https://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/ And the docs can be read online here: https://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/libs/docs/index… The polynomial library contains a single class - polynomial<FieldType> - used for the manipulation of polynomials, along with a selection of algorithms which operate upon them. The library is an extension/ rewrite of the existing "implementation detail" polynomial class in Boost.Math, and was written as part of last years Google Summer of Code under the mentorship of Fernando Cacciola. What to include in 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. The goal of a Boost library review is to improve the library through constructive criticism, and at the end a decision must be made: is the library good enough at this point to accept into Boost? If not, we hope to have provided enough constructive criticism for it to be improved and accepted at a later time. The Serialization library is a good example of how constructive criticism resulted in revisions resulting in an excellent library that was accepted in its second review. 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. Many reviews include questions for library authors. Authors are interested in defending their library against your criticisms; otherwise they would not have brought their library up for review. If you don't get a response to your question quickly, be patient; if it takes too long or you don't get an answer you feel is sufficient, ask again or try to rephrase the question. Do remember that English is not the native language for many Boosters, and that can cause misunderstandings. E-mail is a poor communication medium, and even if messages rarely get lost in transmission, they often get drowned in the deluge of other messages. Don't assume that an unanswered message means you're being ignored. Given constructively, criticism will be taken better and have more positive effects, and you'll get the answers you want. John Maddock. Review Manager for Polynomial Library. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[1.38.0] PDF package of Boost documentation released.
by John Maddock 21 Feb '09

21 Feb '09

Folks, A package containing PDF versions of Boost's documentation is now available for Boost-1.38.0 from the usual sourceforge download site: http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=15971… Please note that due to the diverse range of tools in use within Boost it has not been possible to produce PDF's for all of Boost's libraries, those currently included as PDF's are: accumulators any array asio bimap range complex-tr1 concepts config conversion date_time foreach function hash interprocess intrusive iterator math-gcd math mpi octonion optional phoenix program_options proto python_tutorial quaternion ref regex scope_exit signals static_assert string_algo thread tr1 tribool type_traits typeof units unordered variant xpressive Documentation for the following tools are also included in this package: bjam boost_build boostbook quickbook Regards, John Maddock.

1 0

[boost] Formal Review: Boost.RangeEx
by Thorsten Ottosen 20 Feb '09

20 Feb '09

Dear Developers and Users, It's my pleasure to announce that the review of Neil Groves' RangeEx library starts today and lasts until March 3, 2009. What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. 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. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0