February 2011 - Boost-announce

Boost release 1.46.0 available
by Beman Dawes 21 Feb '11

21 Feb '11

Release 1.46.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 includes 1 new library (Interval Container Library) as well as updates to many existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_46_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

1 0

[Review] Phoenix V3: Mini-review starts February 20th
by Hartmut Kaiser 21 Feb '11

21 Feb '11

Hi all, Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library. This mini-review starts today, February 20th, 2011 and ends on March 2nd, 2011. ------------------ About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. Phoenix is a very important infrastructure library. It is currently a utility library included with Spirit V2 and therefore is already available for years from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_45_0/libs/spirit/phoenix/index.html) ------------------ The code of new Phoenix V3 (that's what we mini-review) can be found at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/ the documentation is at: http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht ml/index.html ------------------ Here are the questions raised during the initial review of Phoenix in September 2008 (see here: http://thread.gmane.org/gmane.comp.lib.boost.devel/180753) <quote> We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times </quote> Please note that Phoenix already has been accepted as a Boost library. We don't vote about that anymore. The purpose of this mini-review is to discuss if the newly rewritten Phoenix V3 addresses the outstanding issues from the main review. In the end I will have to make the decision whether to include the new library into SVN trunk. I really hope to see your participation in the discussions on the Boost mailing lists! Regards Hartmut Review Manager --------------- http://boost-spirit.com

1 0

[Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
by Marshall Clow 06 Feb '11

06 Feb '11

It's my pleasure to announce that the review of Boris Schäling's Process library starts tomorrow, February 7th and lasts until February 20, 2011, unless an extension occurs. What is it? =========== Boost.Process is a library to manage system processes. It can be used to: • create child processes • run shell commands • setup environment variables for child processes • setup standard streams for child processes (and other streams on POSIX platforms) • communicate with child processes through standard streams (synchronously or asynchronously) • wait for processes to exit (synchronously or asynchronously) • terminate processes Getting the library =================== The library is available at: http://www.highscore.de/boost/gsoc2010/process.zip with documentation at: http://www.highscore.de/boost/gsoc2010/ There was a quite involved "informal review" on the mailing list this past summer. That thread is archived here: http://thread.gmane.org/gmane.comp.lib.boost.devel/207594 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 (me!) 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. -- Marshall Review Manager for the proposed Boost.Process library _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[Review][Move] Boost.Move Review Results
by Michael Caisse 01 Feb '11

01 Feb '11

---------------------------- Executive Summary ---------------------------- Ion Gaztañagas' Boost.Move library was reviewed from May 10th, 2010 through May 24th, 2010. The original review manager was OvermindDL1 who later went missing. Eleven individuals joined the discussion with the author. Six reviews were submitted: - 5 reviews ACCEPT - 1 review CONDITIONALLY ACCEPT Ion indicated he would meet the "conditional requirements" which easily satisfies a community vote of: Boost.Move library ACCEPTED ---------------------------- Overview ---------------------------- The Boost.Move library is a highly anticipated addition to the Boost collection. The primary motivation is to introduce usable move functionality in "a portable syntax between C++0x and C++03 compilers"; however, as Vicente Botet articulated, "Most people think that this is an emulation library, but it is more than that as it implements most of the C++0x Move semantics classes and functions." Reviewers' comments: - "This library is long overdue!" [Terry Golubiewski] - "The tutorial is well written." [Vicente Botet] - "Compared to my adobe based move implementation, I think yours is superior." [Daniel James] - "There is a lot of ingenuity in making the move emulation work, and Ion has made it very accessible and managed to make differences between C++03 and C++0x vanish behind macros and free functions." [Jeff Hellrung] An active discussion included: - exposing boost::rv<T> publicly - The merits of fully defining requirements of boost::rv<T>& - Duplicated functionality found in MPL and Type Traits - The necessity for two emulation modes - The merits of macros - Library author usage of Boost.Move - Non-throwing move constructors - Various potentially useful type traits - Other move implementations While it is unfortunate that a timely review result was not published, it did provide an opportunity to discuss some of the concerns raised in the review with actual users of the library. One such concern was the "two emulation modes." At some point in the discussions it became classified as "Safe vs. Fast". When coined with that bias "safe" would be the preference; however, further investigation and inquiries of actual users showed the "fast" version is perfectly acceptable as the default. Additionally, "safe" is a misnomer considering that one mode is not any safer than the other. Each mode has benefits and limitations as enumerated by Ion in the documentation and review responses. The past six months of use would indicate that defaulting to the "fast" version, as preferred by Ion, is in practice a good decision. Thank you Ion for this well thought out and excellent submittal. Thank you reviewers for expending time and energy to further Boost. Without those who are dedicated to review submitted libraries, the entire process and Boost itself falls apart. The community will benefit from the effort each of you put into this library. Best regards - Michael Caisse ---------------------------- Summary of changes ---------------------------- The following changes are planned based on discussions from the review: -- Conditional Acceptance -- 1. "Two Emulation Mode" documentation typos must be resolved. The descriptions, requirements and limitations need to be perfectly clear for the end user. -- Other Issues -- 1. The class rv should be public and documented. 2. is_movable should be renamed and the documentation clarified. It should only be enabled in C++03. A possible alternative name is has_move_emulation_enabled. 3. Nearly all reviewers voiced a preference that the move library should use existing functionality from MPL and TypeTraits libraries. While on one hand this creates a dependency between move and other libraries it results in reuse of accepted and well tested libraries. If a non-coupling option is also provided, it should not be the default. 4. Additional traits discussed. Resolution: add to TypeTraits library as actual use-cases are found. 5. Provide a boost/move.hpp that includes boost/move/move.hpp 6. Document the interaction of the two emulation modes. 7. Include example for making a container "movable". 8. Two emulation modes - Ion was hopeful that reviewers would have a uniform opinion that would result in a single mode. The trade-offs identified by Ion in the documentation were apparent to all reviewers; however, different conclusions were drawn and consensus was not met. The granularity of control was a common issue with nearly all reviewers. Therefore, keep both emulation modes with Optimized as the default and the granularity of control at or more "local level" than the macro provides (class level). 9. emulation_limitations.html: s/overaloading/overloading/ 10. Fully qualify enable_if ( ::boost::emable_if ) 11. Optimized version of forward should use identity so it will not try to deduce T. 12. Make sure required headers are mentioned for tutorials. 13. is_class in is_movable template< class T> struct is_movable : mpl::and_< is_class<T>, mpl::not_< is_rvalue_reference<T> >, is_convertible< T, rv<T>& > > {}; - or - another solution to is_movable problems with references. 14. On throwing move constructors, Ion should follow as close to the standard's behaviour as possible. This can be revisited after the initial release since it is a performance optimization. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0