November 2011 - Boost-announce

Boost 1.48.0 Release Notice
by Beman Dawes 16 Nov '11

16 Nov '11

Release 1.48.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 new libraries: Container, Locale, Move. Updated libraries include: Asio, Chrono, Config, Fusion, Geometry, Graph, Interprocess, Intrusive, Lexical cast, Math, MSM, Numeric Conversion, Proto, Regex, Spirit, TypeTraits, Unordered, Wave, and more. For details, including download links, see http://www.boost.org/users/news/version_1_48_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.48.0/ 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

[boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Jeffrey Lee Hellrung, Jr. 09 Nov '11

09 Nov '11

Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - 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? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function:: overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

1 0

[boost] [atomic] review results
by Tim Blechmann 07 Nov '11

07 Nov '11

hi all, unfortunately only few reviews of boost.atomic arrived in time, however i count 3 YES and no NO, so i am happy to say: Helge Bahmann's boost.atomic library is ACCEPTED. since the library is an implementation of a c++11 feature for c++03, design, API and semantics are mostly fixed. many comments are going into details of the implementation, so i won't sum them all up ... iac, helge already said he wants to address the raised issues, the main points are summarized below. full implementation of the c++11 interface: the library currently only implements a subset of the c++11 library. it lacks the functional interface for integral atomic types and the ATOMIC_VAR_INIT / ATOMIC_FLAG_INIT macro. quickly consulting the latest draft that i currently have at hand the following two functions are missing as well: template <class T> T kill_dependency(T y); void atomic_signal_fence(memory_order); i encourage helge to provide a full implementation of the interface. documentation: the documentation is currently lacking a good API reference. i would therefore encourage helge to provide a doxygen-generated reference section. there were some concerns that it assumes that readers will have to be familiar with concurrency. maybe it is a good idea to point to some literature/tutorials about concurrent programming and/or to c++11 atomics. the section of real-world examples could probably include a link to shavit/herlihy's book `the art of multiprocessor programming'. it would also be helpful to have a detailed specification, if a platform/compiler combination supports a specific type natively (with run-time dispatching or specific compiler flags) ... maybe in form of a table. shared memory support/multi-module support: in multi-module applications and when using shared memory, the blocking emulation of atomics can cause troubles. for multi-module applications this can be resolved by placing the spinlock pool inside a shared library. shared- memory support could be realized by associating a (spin)lock with each blocking atomic<> instead of using a pool of spinlocks. boost should definitely provide atomics which support shared memory, either by default or by an additional implementation which is placed in the boost::interprocess namespace. i would like to thank helge for implementing boost.atomic and submitting it to boost and everyone who participated in the review. cheers, tim review manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[boost] [Boost.Endian] Review Results
by joel falcou 03 Nov '11

03 Nov '11

Hi everyone, after some delay, here is the result of the review of Beman Dawes' Boost.Endian library. First, I want to thanks all participants of the review that lead to very deep and interesting discussions on the matter. 5 votes were cast : 2 unconditionally in favor, 3 conditionally in favor after changes made and there is a mini-review. The verdict is that Boost.Endian is **CONDITIONNALY ACCEPTED** Here is what needs to be done to get the library ready for a mini-review: * Common use case scenarios should be developed. * Example programs should be developed for the common use case scenarios. * Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications. * Conversion functions supplying results via return should be provided. * Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported. * Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies. * Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios. * Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case. * Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns. * There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated. * Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage. * Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library. From this point, I will let Beman prepare Endian for the mini-review and I already volunteer to manage the mini-review so informations are not scattered around. Regards _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0