August 2011 - Boost-announce

[Review] Review results for Lockfree
by Hartmut Kaiser 22 Aug '11

22 Aug '11

All, The review for the Lockfree library written by Tim Blechman started July 18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Tim Blechmann's Lockfree library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The design of the library is sound, the API is usable. Except for naming issues (discussed below) almost no comments have been made on how to change it. People reviewing the library would like to see a more modular approach to lockfree data structures in general, possibly by exposing building blocks or by utilizing policies. The general interest was to have a more diverse set of data structures available, such as a lock-free linked list or bounded and fixed-sized data structures. Atomics Library --------------- As the initial review announcement stated, Lockfree depends on an external Atomics library, which has to be separately reviewed in order to get into Boost as a first class library. There has been some discussions whether Lockfree could be accepted without Atomics being reviewed. Others suggested Lockfree may be reviewed and added to Boost SVN only after Atomics got reviewed (this was mentioned in the review announcement as well). After all those discussions and based on the wide interest Lockfree data structures have, I'd suggest to add the current Atomics library as an implementation detail to Lockfree. Special handling of compilers which already have implemented std::atomics would be good if added to Lockfree, though. Naming ------ The consensus was that the naming of the reviewed data structures has to be changed. The names should be either fifo and lifo or queue and stack. AFAIK, Tim already addresses this point. Documentation ------------- The consensus of almost everybody referring to the documentation was that it needs more work. Here is a short (but non-exhaustive) list of things being mentioned: - It lacks rationale and information about the implementation - The class synopsis of the data structures should be accessible from the "Reference" page. - Make non-thread-safe parts more explicit (fifo::empty is described as non-thread-safe) - Document exception guarantees - More information needed on internals, the design, and rationale I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://boost-spirit.com

1 0

[boost] [review] Conversion review starts today
by Gordon Woodhull 19 Aug '11

19 Aug '11

Hi All, The review of Vicente Botet Escriba's Conversion library starts today and ends August 29. The Conversion library manages generic explicit conversion between unrelated types. It can be thought of as a substitute for overloading static_cast, or as an alternative to lexical_cast when conversion via text is unwanted. The code is available here: http://svn.boost.org/svn/boost/sandbox/conversion/ And the documentation is here: http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… Alternately, you can download a compressed package here: https://github.com/viboes/TBoost.Conversion Reviews may answer the following questions: * 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. Of course, "informal reviews" and discussion are also welcome. Cheers, Gordon Woodhull Espen Harlinn _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[boost] [Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by John Maddock 03 Aug '11

03 Aug '11

The review of the containers library by Ion Gaztanaga starts today, to summarize the library: "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. In short, what does Boost.Container offer? * Move semantics are implemented, including move emulation for pre-C++0x compilers. * New advanced features (e.g. placement insertion, recursive containers) are present. * Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). * The library offers new useful containers: o flat_map, flat_set, flat_multiset and flat_multiset: drop-in replacements for standard associative containers but more memory friendly and with faster searches. o stable_vector: a std::list and std::vector hybrid with random-access iterators that offers iterator stability in insertions and erasures. o slist: the classic pre-standard singly linked list container." Documentation from the library may be viewed online here: file:///M:/data/boost/sandbox/move/libs/container/doc/html/index.html The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Review comments might like to answer the following questions: * 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. Regards, John Maddock. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[boost] [TTI] Review Result
by Joel falcou 02 Aug '11

02 Aug '11

This is the result summary for the Type Traits Introspection library by Edward Diener. The review have been on going from July 1st to july 17th and had generated a large amount of very interesting design discussion. The library received 5 Positive reviews and a few positive comments next to that. **The verdict is that, the TTI Library is ACCEPTED into Boost.** However, a few comments and concerns have been raised but are rather simple changes to perform and I am sure Edward will take these comments into account before releasing the library. Such comments include: * The main comment is the fact that Boost.TTI force the definitions of its meta-functions into the boost::tti. Concerns have been raised and requests made that the macro don't specify any namespace and let users bring the generated meta-functions in the namespace of their own liking. * The number of macros handling various corner cases has been raised as potentially too high. Effort to streamline the macro based interface has been requested. * Support for more compiler is needed. Some issues on ICC has been raised but are currently being looked upon (or fixed). * Naming scheme of the macro and of the generated meta-functions have to be refined to be 1/ more clear 2/ avoid some non-standard name starting with __ * Some more detailed and entry-level examples may be beneficial to the library * Pre-made macro for classical typedef like value_type or other std components has been proposed Thanks to all the participants and to Edward for this review. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0