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

[boost] [constrained_value] Constrained Value review results
by Gordon Woodhull 11 Sep '10

11 Sep '10

Greetings, Substituting for Jeff Garland, I am pleased to present the results from the constrained_value review. The library is available at http://rk.dl.pl/f/constrained_value.zip The documentation is at http://rk.dl.pl/r/constrained_value Enjoy! Gordon 1. History The idea for a constrained value library goes back to at least 2004; Christopher Diggins proposed a mini-library at that time. In 2007 Joe Gottman suggested that Jeff Garland's constrained_value.hpp in date_time could be a top-level library. Concurrently, Robert Kawulak (henceforth RK) was working on his own library for the purpose, which he also started in 2004, unaware of the others. RK announced his library on November 11, 2007. Discussion continued into 2008; on June 19, RK announced his library was ready for review and it was put in the queue. The review began on December 1 2008 and continued until around December 15 (with some trailing discussion of the definition of invariant and why exceptions should not be used to check invariants). Gordon Woodhull reviewed the thread's 260 messages in the summer of 2010 and produced this report, dividing the issues raised between those where there was consensus on a change, those where no resolution was found, and those where the author and requesters (mostly) agreed that no change was needed. 2. Votes Eight people voted for acceptance of the library; there were no "no" votes. However, many people stated conditions on acceptance. Thanks to Chris (indy271828(a)sympatico.ca) Vicente Botet, Zach Laine, John Maddock, Thorsten Ottosen, Stjepan Rajko, Daryle Walker, and Gordon Woodhull for providing reviews. (In addition, Paul Bristow provided a review which looks like a yes but does not explicitly say so.) Thanks also to David Abrahams, Kim Barrett, Neal Becker, Paul Bristow, Edward Diener, Jeff Flinn, Joe Gottman, Mathias Guanard, Mika Heiskanen, Giovanni Pierro Deretta, Thomas Klimpel, Michael Marcin, OvermindDL1, John Phillips, raindog, Ravi (lists_ravi(a)lavabit.com) Johan Råde, Sebastian Redl, Peter Simons, Steven Watanabe, Utku Yaman, and Deane Yang for participating in a very active discussion. 3. Issues to be Addressed Floating point By far the most contentious issue in the review was the statement in the library documentation that floating point is not supported, and a few reviewers made fixing this a condition on acceptance. The issue is that the x87 math instructions (which are the default for 32-bit Intel compiles) utilize 80-bit registers which are then rounded down to 64 bits when a double value is written to memory. This can cause two values which were not equal to become equal later, with fairly unpredictable behavior depending on optimization and what code intervenes between calculating a value and comparing it. One solution is simply not to use the x87 math instructions by enabling the SSE2 math instructions instead. However, users may want the extra precision, and there is no way for a library to control this option. A few reviewers confused this issue with the frequent need for fuzzy comparison with epsilon; it was shown that the bug can still appear with epsilon-based comparisons. Jeff Garland points out that the Boost Numeric Interval library, http://www.boost.org/doc/libs/1_42_0/libs/numeric/interval/doc/interval.htm has also dealt with the x87 and NaN problems. It uses the round-trip-to-memory approach for x87. There is potential to create constraints for constrained_value using numeric::interval, and perhaps any other fixes for floating point belong in that library. Many solutions were proposed; after debate there were four left standing: * Force the new value to be written to memory Kim Barrett suggested the following function, noting that it should not force a memory write unless the value is in a register. inline double exact(double const& x) { return *const_cast<double const volatile*>(&x); } Gordon Woodhull has tested this against example provided by Thomas Klimpel in a message titled "floating point FUD" of January 23, 2010 (http://article.gmane.org/gmane.comp.lib.boost.devel/198817) and it does work. However, many people objected to this solution because of efficiency concerns: it requires a round-trip to memory (or at least to cache) for every assignment. * Only allow >= or <= for floating point types, and make sure the bounds are truncated 80- to 64-bit truncation can cause two values to become equal, but if one of them is already truncated, it cannot cause them to swap order. Since it is likely that the value will be changed much more frequently than the bound, it would suffice to apply truncation just to the bounds when they are set, e.g. with the exact() function above. However it does not seem that this solution can work if the bounds are dynamically calculated; the library supports bounds being returned by an inlined function. Johan Råde also suggested that it might be possible to implement < and > in terms of <= and >= and the std::nextafter function. * Force the processor to use 64-bit precision Johan Råde mentions a floating point control register which could be used in http://article.gmane.org/gmane.comp.lib.boost.devel/183760 There were also mentions of possible assembly code solutions, but none were provided and this was generally unpopular because it requires someone very knowledgeable to maintain it. John Phillips argued that reducing the precision will "lose significance faster than expected". * Another interesting solution was suggested by Stjepan Rajko: that the test might not be the same as the invariant. This is what testing with epsilon would guarantee. If the value passes the test it is guaranteed to satisfy the invariant, but only the test and not the invariant is in code. So some values might be rejected which are okay, but no bad value is accepted. RK felt that any floating point solution should be implemented separately from constrained_value, because he does not have the expertise. But he should be willing to document the scope of the problem better, including the SSE2 compiler flags that avoid the problem altogether. The first solution (truncation of the value) does not seem to require any changes to the library. Truncating the bounds might require some extra customization points. NaN Another problem with floating point is NaN, which compares false with everything. It might be okay if the bounds inclusion test always returned false. But the closed range is implemented as !(x < lower) && !(upper < x). Stjepan Rajko suggested that it should always be compare(lower, x) && compare(x, upper) where compare is < for excluded bounds and <= for included. It seems like this solution would work well for floats but not necessarily for user-defined types, which might only define operator<(). Substitutability with the underlying type A few people requested the ability to set a compiler flag in order to substitute the constrained_value with the underlying type. This is not exactly possible, unless the user is willing to explicitly extract the value using static_cast<T>(cv). The library does provide unconstrained<> which in most cases optimizes away, but the interface is not perfectly compatible with the underlying type. Constraints not copied when operators used The use of operators invokes implicit conversion to the underlying type, which means that in a statement like constrained_value x(10, constraint(...)), y(-x); y ends up with uninitialized constraints. Steven Watanabe suggested that the operators could be overloaded, but RK argued that the behavior would be application-specific: "For some applications returning a constrained value would be OK (but again there is the problem that the constraint may reject the modified value) while for others it's better to return the underlying type." Constrained strings Jeff Garland offered that he has written constrained_string classes for allowing values from a set of strings, and for validation against a regex. RK said he might add a constraint type which validates against set<T>, and affirmed that a regex validator would be nice too. Bounding on only one side Utku Yaman and others requested a way to bound integers on only one side. RK noted that you could set one of the bounds to the maximum or minimum possible integer, but this is verbose. Default arguments would be confusing, and RK thought maybe he would supply lower_saturating_int and upper_saturating_int. Note that there is a more general problem, especially if floating point is allowed. (Also consider e.g. fixed point, rational.) Recoverable error policy - error policy changing the value There were some objections to the error policy taking three parameters - the new value, the member value, and the constraint. Does it really need to change the member value? Yes, RK explained, because this is a recoverable error policy. Vicente Botet asked that the concept be called RecoverableErrorPolicy. Serialization Neal Becker requested support for serialization. RK agreed this is worth looking into and pointed out a couple of difficulties. One, a way to not serialize empty (or static) policies is needed. Two, non-default constructible types such as odd_number might require use of load_construct_data() / save_construct_data() instead of serialize(). Rename bounded_int This class name does not convey the fact that the bounds are specified at compile time. Neal Becker suggested compile_time_bounded or static_bounded. RK says the first name is too long, and the second might imply that the bounds are static members (which is also a legitimate use case). sizeof static constrained types == sizeof underlying type Assuming that the empty base class optimization is being applied correctly, which seems to be the case, if the constraint and the error policy are empty, the size of the constrained value should be the same as the size of the underlying type. However, this was not the case on all platforms, at least at the time of the review. The library should include sizeof tests in its test suite so that potential users know if there is unexpected overhead on their platform. Specify static bounds as open<0>, closed<100> for bounded<> and bounded_int<> Requested by Vicente Botet. If possible, this would reduce the number of template arguments and would be more clear than the current bounds exclusion boolean parameters. Some default constructions may throw If zero does not satisfy the constraint, then a default-constructed constrained value may throw an exception. (There are other examples, like non-empty string.) Many reviewers requested a means to provide a default value, which can be done by wrapping the underlying type, but RK felt a default value class was out of scope. At the very least this should be documented and probably an example given. Examples Vicente Botet requested: * an example showing how to create a constrained class by derivation and/or containment which adds/removes methods from the constrained value interface * a date example where changing the month affects the bounds for the day. * example of static bounding on only one side * example of bounds calculated at runtime by a function ("runtime dynamic bounding") Others: * example of constraints with static members - allows shared mutable constraints with no overhead per instance. Tests! Many reviewers were offended that there were no tests in the review version. RK said he would write some. Documentation * document the concepts and provide tests with concept archetypes. It turns out that these are documented briefly in the doxygen documentation of constrained<> at http://tinyurl.com/39v8o6r, but many reviewers were expecting a section in the main document. * Stjepan Rajko pointed out that the constraint can't depend on mutable members of the underlying type, and wondered if there were other implicit requirements, such as the way copy construction or swapping works. He requested these be documented. * Gordon Woodhull suggests a section on space efficiency and which configurations should allow the size to be optimized to the same size as the underlying type, and spelling out in each example what the cost in space is. * Thorsten Ottosen requested benchmarks of non-checking unconstrained against just using the underlying type. RK offered that he had looked at the generated assembly on some platforms. 4. Unresolved debates Error policy is allowed to change constraint Vicente Botet objected to the "bounded object with memory" example, which tracks extremal values by setting the bounds to include any new values. And Thorsten Ottosen objected to the inefficiency of change_constraint using construct-and-swap: it's not necessary to swap the constraint unless it might be changed by the error policy. This seems to be an example of a monitored value, which RK does not want to write himself, so does it belong in this library? RK argued that it does no harm, so why not allow? Double-checking and disabling assertions A number of people were concerned with the inefficiency of first checking the constraint, and then also asserting that the constraint is satisfied after the assignment has happened or the error handler has been called. But RK argued that it was necessary to check the invariant to make sure that the assignment operator and the error handler are doing their job. Besides, it is possible to disable the asserts with either BOOST_DISABLE_ASSERTS or NDEBUG. There was some discussion of adding an assert policy or a specific macro (with no clear conclusion). Disabling checks There is unconstrained, which offers a way to replace one constrained type with an unconstrained type, but Chris (indy271828(a)sympatico.ca) requested a way to disable all checks with a single macro. It might not be good enough to use a single error policy and select between throwing version and an assign-anyway version, because the compiler won't always optimize this away. More members, less free functions Thorsten Ottosen thought that any functions which change the state of the object should be members, not free functions. In particular, change_constraint might be less efficient than possible because the construct-and-swap requires copying the constraint. This does seem to be partly an ideological debate. Specific classes instead of a general super-template Vicente Botet requested that the interface use specific classes instead of typedefs: currently many of the specializations, like bounded<>, are metafunctions that apply some parameters to the generic constrained_value and return a new type, and then the specific operations are free functions. Instead these could be full classes with member functions. RK argued that this would result in unnecessary duplication. Way to disable the arithmetic operators Vicente Botet requested a solution in code or in documentation for users who don't want the arithmetic operators defined. 5. Ideas not requiring any action Monitored Values Stjepan Rajko suggested (and Vicente Botet expanded on the idea) that constrained value is really a special case of a more general "monitored value" class, in which a monitor policy decides how to handle any assignment. So constrained value would be a monitored value where the monitor policy checks a constraint, possibly calls an error policy, and then asserts the constraint. RK did not want to implement this and resisted suggestions to allow the assertion to be disabled in order to allow this use case, because without an invariant, it's not really a constrained value. But he suggested that monitored value could be implemented by someone else and constrained value could be re-implemented in terms of it. "Monitored value" might not be the best name for the general class, because "monitor" suggests something passive, rather than something which controls the outcome of assignment. A way to run a function on a constrained value Stjepan Rajko requested a way to make a copy of the value, run a function on it, and then reassign back, preferring the syntax call_using_copy(f, x) to x = f(x). But he notes this could be written as a free function. Multiple ranges Edward Diener requested a way to supply multiple ranges, but agreed that the syntax would be unattractive. Assertions instead of exceptions Thorsten Ottosen requested a way to have only assertions and no exceptions, and RK pointed out that this can be done either by specifying an error policy which asserts, or even with an assign-anyway error policy, which leaves the invariant checking in place. Exclude bounds parameter Vicente Botet found it confusing that bounded_int takes false to mean include bounds and true to mean exclude the bounds. RK explained that this is an artifact of the way within_bounds is templated on a type which can be either a compile-time or a runtime value, e.g. mpl::true_ or bool; this technique means there can be no default argument to the constructor and thus the more common option must be false, the default constructed value of bool. Constraints between several variables. Vicente Botet suggested a sort of constrained_tuple where if you set one field it would affect the constraints for the other fields. E.g. a date object where the month and year would affect the valid range for the day. With the current interface you'd have to set the whole date at once. Constrained values as sets of instances Exploring the problem domain, Vicente Botet suggested another possible implementation of constrained value where the constrained value type keeps track of which instances satisfy the constraint. This class would offer a split operation which moves any instances which satisfy a more specific constraint into the new set. Changing the constraint would similarly return the set of instances which are now excluded. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost Release 1.44.0 is now available
by Beman Dawes 17 Aug '10

17 Aug '10

Release 1.44.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraies (Meta State Machine & Polygon) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/download/version_1_44_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

1 0

[mini-review] Update of Boost.Assign (13th-19th of June)
by Thorsten Ottosen 13 Jun '10

13 Jun '10

Dear Boost Developers and Users, Erwann Rogard has implemented an update to Boost.Assign which we shall evaluate during the next week. His extensions allows one to write code like the following: (A) A list of references (to temporaries, in this example): boost::array<int,8> a = cref_csv( 1,5,3,4,2,9,0,7 ) (B) Chained ranges: vector<int> v = vector<int>( 3,1 ) && vector<int>( 3,2 ); If you have comments and suggestions about these new features, please submit a small review or voice your oppinion on the Boost developer list. If you have other feedback for Boost.Assign, now would be a good time to mention them too. If you submit a review, please follow the guidelines here: http://www.boost.org/community/reviews.html#Comments To access the new docs, please see https://svn.boost.org/svn/boost/sandbox/statistics/support/libs/assign/doc/… To access the new code, please see https://svn.boost.org/svn/boost/sandbox/statistics/support/boost/assign/ best regards Thorsten Ottosen, Review Manager

1 0

Review Wizard Report for May 2010
by Ronald Garcia 26 May '10

26 May '10

============================================== Review Wizard Status Report for May 2010 ============================================== News ==== Boost 1.42 Released New Libraries: UUID Revised Libraries: Asio, Circular Buffer, Fusion, Graph, Integer, Iostreams, Program.Options, Property Map, Proto, Regex, Spirit, Unordered, Xpressive Meta State Machine (MSM) Library Accepted Boost 1.43 Released New Libraries: Functional/Factory, Functional/Forward Revised Libraries: Range, Accumulators, Array, Asio, Fusion, Iostreams, Multi-index Containers, Proto, Random, Spirit, Thread, Unordered, Uuid, Wave, Xpressive Open Issues =========== The Constrained Value Library was reviewed in December 2008 but no review result has been reported. We would appreciate it if someone who knows the review manager, Jeff Garland, could contact him. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Time Series (accepted August 2007). * Floating Point Utilities (accepted March 2008). * Futures (accepted April 2009). * Polygon Library (accepted November 2009). * Geometry Library (accepted November 2009). * Meta State Machine (accepted January 2010). The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Switch (accepted provisionally January 2008) * Phoenix (accepted provisionally September 2008) General Announcements ===================== As always, we need experienced review managers. The review queue has grown substantially but we have 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. The included review queue isn't a classic queue. It is more an unordered list of the libraries awaiting review. As such, any library in the queue can be reviewed once the developer is ready and a review manager works with the wizards and the developer to schedule a review. It is not FIFO. Review Queue ============ * Lexer * Shifted Pointer * Logging * Join * Pimpl * Task * Endian * Conversion * Sorting * GIL.IO * AutoBuffer * String Convert * Containers * Type Traits Extensions * Interthreads * Bitfield * Lockfree * Fiber * Chrono * Sequence Properties * Static Size Linear Algebra * Locale -------------------- 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! 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. Task ---- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: Formerly called Thread Pool 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 newest 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: 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. Containers ---------- :Author: Ion Gaztanaga :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… :Documentation: http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… :Description: Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. Type Traits Extensions -------------------------- :Author: Frederic Bron :Review Manager: Needed :Download: http://svn.boost.org/trac/boost/browser/sandbox/type_traits :Description: The purpose of the addition is to add type traits to detect if types T and U are comparable in the sense of <, <=, >, >=, == or != operators, i.e. if t<u has a sens when t is of type T and u of type U (same for <=, >, >=, ==, !=). The following traits are added: is_equal_to_comparable<T,U> is_greater_comparable<T,U> is_greater_equal_comparable<T,U> is_less_comparable<T,U> is_less_equal_comparable<T,U> is_not_equal_to_comparable<T,U> The names are based on the corresponding names of the standard template library (<functional> header, section 20.3.3 of the standard). The code has the following properties: * returns true if t<u is meaningful and returns a value convertible to bool * returns false if t<u is meaningless. * fails with compile time error if t<u is meaningful and returns void (a possibility to avoid compile time error would be to return true with an operator, trick but this has little sens as returning false would be better) InterThreads ------------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :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. Bitfield --------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :Download: http://svn.boost.org/svn/boost/sandbox/bitfield with documentation available at http://svn.boost.org/svn/boost/sandbox/bitfield/libs/bitfield/doc/index.html :Description: Portable bitfields traits. Boost.Bitfield consists of: * a generic bitfield traits class providing generic getter and setter methods. * a BOOST_BITFIELD_DCL macro making easier the definition of the bitfield traits and the bitfield getter and setter functions. Lockfree ------------------ :Author: Tim Blechmann :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… ; :Documentation: http://tim.klingt.org/boost_lockfree/ :Description: boost.lockfree provides implementations of lock-free data structures. lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack the code is available from from my personal git repository: * git://tim.klingt.org/boost_lockfree.git * http://tim.klingt.org/git?p=boost_lockfree.git Fiber ----- :Author: Oliver Kowalke :Review Manager: Needed Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… ; :Description: C++ Library for launching fibers (micro-threads) and synchronizing data between the fibers. Chrono ------ :Author: Vicente Botet :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ch… ; :Documentation: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht… . :Description: The Boost Chrono library provides: The C++0x Standard Library's common_type. The C++0x Standard Library's compile-time rational arithmetic. The C++0x Standard Library's time utilities, including: Class template duration Class template time_point Clocks: system_clock monotonic_clock high_resolution_clock typeof registration for classes duration and time_point Process clocks: process_real_CPU_clocks, capturing real-CPU times. process_user_CPU_clocks, capturing user-CPU times. process_system_CPU_clocks, capturing system-CPU times. process_cpu_clock, tuple-like class capturing at once real, user- CPU, and system-CPU times. Stopwatches: stopwatch, capturing elapsed Clock times. stopwatch_accumulator, capturing cummulated elapsed Clock times. scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. Stopclocks or Stopwatch reporters: stopwatch_reporter, convenient reporting of models of Stopwatch results. stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Support wide characters for stopwatch formatters Sequence Properties ------------------- :Author: Grant Erickson :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=cr… :Description: The creasing algorithm templates define four template functions for determining the order properties of sequences, specifically: * Increasing * Decreasing * Strictly Increasing * Strictly Decreasing The implementation is a fairly trivial composition of the STL adjacent_find, not2 and {greater,less,greater_equal,less_equal}. For the purposes of sequence ordering validation, using these templates is more efficient and straightforward than creating a temporary, sorted version of some sequence and comparing it against the original sequence. Example: :: bool CheckPoints(const Points & inPoints) { const bool strictlyIncreasing = is_strictly_increasing(inPoints.begin(), inPoints.end()); if (!strictlyIncreasing) { cerr << "Points must be in increasing order with " "no duplicate values." << endl; } return strictlyIncreasing; } Static Size Linear Algebra -------------------------- :Author: Emil Dotchevski :Review Manager: Needed :Download: :Description: Locale ------ :Author: Artyom Beilis :Review Manager: Needed :Download: https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale_for… :Description: Boost.Locale is powerful localization library that provides powerful localization tool extending existing built-in C++ localization facilities in Unicode aware way. Libraries under development =========================== Persistent ---------- :Author: Tim Blechmann :Description: A library, based on Boost.Serialization, that provides access to persistent objects with an interface as close as possible to accessing regular objects in memory. * object ownership concepts equivalent to the ones used by Boost.SmartPtr: shared, weak, scoped (and raw) * ACID transactions, including recovery after a crash and "Serializable" isolation level * concurrent transactions, nested transactions, distributed transactions * concurrent access containers: STL containers whose nodes are implemented as persistent objects and can be accessed without moving the container to memory. Concurrent transactions modifying the container are only repeated in the rare cases the same container node is changed simultanisouly by 2 threads. * extensible by other transactional resources, e.g. an object relational mapper based on the upcoming Boost.Rdb library. Multiple resources can be combined to one database, with distributed transactions among them. Please let us know of any libraries you are currently developing that you intend to submit for review. See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[Review] Formal Review: Boost.Move
by OvermindDL1 25 May '10

25 May '10

Greetings Boost Developers and Users, It's my pleasure to announce that the review of Ion Gaztañagas' Move library starts May 10th and lasts until May 24th, 2010, unless an extension occurs. What is it? =========== The Boost.Move library would supply an emulated C++1x Move semantics interface, aka RValue References, allowing for a wide variety of easy to use and easy to add in optimization abilities. The most used function it would add would be: val_b = boost::move( val_a ); Which would move val_a to val_b; val_a should not be used after this line. This semantic allows for a vast amount of optimizations, especially in regards to temporaries, see the documentation for further examples and use. Other patterns emulated are && rvalue references for functions/members and constructors. There are also a number of STL containers in the sandbox that support move semantics using this library for higher efficiency. Getting the library =================== The latest version of this library may be downloaded from SVN: http://svn.boost.org/svn/boost/sandbox/move/ and the docs may be viewed here Docs: http://igaztanaga.drivehq.com/libs/move/doc/html/index.html and do note, this library is header-only and is designed to be absolutely generic to be useful in all areas of C++ programming. 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 ====================== If you want or need a primer on the subject, please look at the working draft for C++1x. This linked site has also been shown to be quite useful in describing move usefulness: Want Speed? Pass by Value.: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ Move It With Rvalue References: http://cpp-next.com/archive/2009/09/move-it-with-rvalue-references/ And there are further links in that series, but those two will get you started in the domain. Best regards, OvermindDL1, Review Manager (Boost.Move)

1 2

[1.43.0] Release notice
by Beman Dawes 06 May '10

06 May '10

Release 1.43.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries (functional/factory, functional/forward), a major range library upgrade, plus numerous enhancements and bug fixes for other libraries. For details, including download links, see http://www.boost.org/users/news/version_1_43_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/1_43_0/more/getting_started/index.html Thanks to all who contributed, --The Boost release team

1 0

[Review] [ITL] ITL formal review results
by Hartmut Kaiser 18 Apr '10

18 Apr '10

Hi all, The formal review of the Interval Template Library (ITL) written by Joachim Faulhaber started February 18th and ended March 7th, 2010. We saw a lively discussion resulting in 14 votes: 10 people voted unconditionally YES, 3 voted conditionally YES, and 1 reviewer voted NO. The overwhelming majority of the votes was YES which reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions we saw the Interval Template Library is now formally accepted into Boost. Detailed results ---------------- Pros: Almost all reviewers highlighted the general usefulness of the library. The more experience the reviewers had with the library in real world applications the more they emphasized its usefulness. Here are some quotes: - "ITL solved this problem for me, in a way that honestly freed me from having to think about a lot of the unsavory low-level details." - " Until now, we only used the library for intervals of date-times (coded as integers), but I'm sure, that its usefulness goes far beyond." - " Very useful. I mentioned two projects where the library would have helped me if it had been into Boost earlier, and I'm considering rewriting them such that the problems make use of the library, and simplify them in that way." The comments on the quality of the documentation are unanimous: "impressive and quite complete", "I couldn't ask for more". It seemed to be generally helpful to understand the concepts of the library and to get started. Some people asked to add more simple quick-start examples to the documentation and the distribution. Overall, the library is mature and easy to use. All reviewers actually utilizing the ITL library for real world use cases reported they were able to start quickly and without problems. All reviewers using ITL in real world applications stated that no performance problems were encountered. This is important to note as the NO vote was based on the current lack of a interval tree implementation, which was considered to result in suboptimal performance for certain use cases. Cons: Some aspects of the design have been criticized: "OO-type design decisions", "fat 'one size fits all'-interval class template", and "incomplete extraction of global functions" are the major points of critique. These points have real merit. In order to make the design and interface more flexible and more durable these have to be rectified before the final inclusion of the library into Boost's code base. Joachim already agreed to a list of things to change addressing those problems. For certain use cases, specifically for interval map of collections, the current implementation has suboptimal complexity characteristics that leads to O(n^2) space usage in the worst case. OTOH, for the majority of applications of the library the worst case scenario seems to be (reportedly) irrelevant. This issue has been discussed at length and Joachim plans to add an implementation with a better worst case performance of the affected class templates as later optimizations. This is not considered to be a precondition to full inclusion into Boost's code base as it is not anticipated to cause any interface changes. Last but not least people suggested to change the name of the library as having the word template in the name does not carry any useful information. Joachim already agreed to this. Regards Hartmut Review Manager --------------- Meet me at BoostCon www.boostcon.com

1 0

[boost] [log] Boost.Log formal review result
by Vladimir Prus 24 Mar '10

24 Mar '10

First of all, I would like to thank Andrey for this submission and the active discussion during the review. I also would like to thank everybody who participated in the review. The comments on the library were generally positive. Several reviewers have tried it in practical projects already, and found it superior to other libraries. It clearly will benefit the users of Boost right away. Therefore, the library is accepted. Congratulations, Andrey! On the other hand, some concerns about the ease of use and performance and implementation details were raised. Of those, some can be easily addressed as part of normal maintenance, while some seem to require significant rework and may change the library quite consirably. Therefore, the library is accepted subject to several conditions -- listed below under "Critical issues". Because the changes can be large, I think a mini-require is required when those issues are addressed. To avoid delays, it's probably not necessary to formally schedule and conduct a mini- review -- just posting a email asking for discussion will be sufficient. Statistics ========== There were roughly 300 emails during formal review (I have a mbox archive if anybody needs it). The following persons submitted a review with a vote. Some of votes are "provisional", this is not reflected below, but affects the list of critical issues below. - Boris Schaeling (yes) - Roland Bock (yes) - Ralf Globisch (yes) - Sean Chittenden (yes) - Darryl Green (no) - Tom Brinkman (no) - Barend (yes) - Sam Gundry (yes) - Vicente Botet (yes) - Robert Stewart (yes) - Alexander Arhipenko (yes) - "M-Square" (yes) Critical issues =============== These issues must be addressed, and be passed through informal mini- review, before the library can be added to SVN. - It appears that the 'trivial' logging is not sufficiently good to just take and use. The library should provide an out-of-the-box mechanism that: - supports channel/severity attributes, without creating new logger for each severity. It also should be possible to filter out specific channel by essentially poking at some "map", and without manually composing a new filter that checks for a set of allowed channels sequentally. I believe that at least Christian, Roland, Robert and myself requested this. - has no observable effect on compile time. One second (or more) that trivial.hpp imposes is not acceptable. - outputs to console by default, but permits changing that - outputs only component/severity/message by default, but probably permits changing that. - By default, the library should try hard to continue working no matter what errors happen during processign a log record -- including things like invalid attribute names or types, or other exceptions. - The library should not reinvent wheels. In particular, custom implementations of TSS and RW mutex seems like a very bad idea. Use of a custom lambda implementation was pointed by many as not great -- we already have a couple, so let's not add more to the mix. - Library interface is too geared towards lambda. In particular, implementing formatters/filters as free-standing functions appears to require considerably more code. In particular, it should be possible to access an attribute using a single function call. Also, logging::extract taking a lambda for callback complicates matters, it's desirable to have a more direct variant. Important issues ================ These issues are important enough to be mentioned here, but can be addressed as convenient. - The reported run-time performance can be improved. In particular the performance with date attributes seems scary and 2x slowdown relative to some other library in the 'most records are filtered out' case is also concerning. - I don't think it was satisfactory explained why 'attr' exists in two namespaces, as opposed to being a single type that is used for both formatting and filtering. Other notes =========== These issues seem important and should be considered, but might not even be fixable within the current design. - Several reviewers said the library is "too flexible" and this makes it harder to understand. Probably nothing can be done about that at this point, but interesting data point notwithstanding. - It was suggested that the library include an API that another Boost log may use in a way that permits plugging another logging library should end user of a Boost so desire. This seems a good idea, but I think it's up to Andrey to implement such API or not. - Alternative design approaches were proposed, in particular (i) permitting user log records and templating/basing other components on a user- defined record type and (ii) using compile-time indexing to access attributes. Also, it was proposed that named parameters not be necessary to use the library, and a more conventional interface be available. It does not seem that implementing those suggestions is fully possible without writing a different library from scratch, so it's up to Andrey to consider those proposals. - It was suggested to use newer Spirit to address poor compile times for the library itself. Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Review] The review of the ITL library ends today, March 7th
by Hartmut Kaiser 07 Mar '10

07 Mar '10

Hey all, The review of Joachim Faulhabers ITL library ends today, March 7th 2010. Please get your reviews in today or get in contact with me to agree on some offline schedule. Regards Hartmut Review Manager --------------- Meet me at BoostCon www.boostcon.com

1 0

[Review] ITL review extended until March 7th
by Hartmut Kaiser 28 Feb '10

28 Feb '10

Hey all, After getting the approval from our review wizards we decided to extend the review period of Joachim Faulhabers ITL library until March 7th, 2010. That should give everybody some more time to finish their reviews. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0