- Boost - lists.boost.org

[1.51.0] release candidates available
by Marshall Clow 19 Aug '12

19 Aug '12

Release candidate files for 1.51.0 are available at http://boost.cowic.de/rc/ At this point, the release branch is closed for changes without explicit permission from the release managers. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 6a1f32d902203ac70fbec78af95b3cf8 *boost_1_51_0_rc1.tar.gz 4b6bd483b692fd138aef84ed2c8eb679 *boost_1_51_0_rc1.tar.bz2 ee8112e48088b05c248d68329cd5d908 *boost_1_51_0_rc1.zip e87d3747966ab7e0c9487884326d7d17 *boost_1_51_0_rc1.7z Thanks, --The release managers

5 6

Modularized Boost: How the files in libs/libXX must be included?
by Vicente J. Botet Escriba 19 Aug '12

19 Aug '12

Hi, the following ticket https://svn.boost.org/trac/boost/ticket/7200 report an issue while building Boost.Thread using the modularized cmake. What is the correct way to include the files in lib/libXXX? Best, Vicente

2 1

[type_traits][parameter] Inconsistent boost::is_convertible between gcc and clang
by John Bytheway 19 Aug '12

19 Aug '12

I have been tracking down an issue with some of my code which compiles fine with gcc but not clang. It manifested as a failure in Boost.Parameter but I eventually pinned it down to an inconsistency in the behaviour of boost::is_convertible. The following program demonstrates the issue: ============== #include <boost/type_traits/is_convertible.hpp> #include <boost/static_assert.hpp> class A {}; int main() { BOOST_STATIC_ASSERT((boost::is_convertible<A, A&>::value)); } ============== This compiles fine under g++ (4.7.1), but the assertion fires under clang++ (r160940). This is not too surprising because is_convertible is implemented in completely different ways on the two compilers: - on clang it is in terms of the __is_convertible intrinsic, which behaves like std::is_convertible and fails because rvalue references don't convert to lvalue references. - on gcc it has a complex custom implementation which at some point performs add_reference<> on the first argument and thus determines that the conversion is OK. Reading the docs for boost::is_convertible I think the clang interpretation is closer to the intention, in which case the gcc implementation is wrong, and so is Boost.Parameter (which relies on this behaviour). On the other hand, I suspect there's probably other code out there that depends on this in a similar way to Boost.Parameter, so perhaps it would be safer to tweak the clang implementation instead, and deviate from std::is_convertible. Any thoughts? John Bytheway

5 13

[odeint] Iterator semantics
by Karsten Ahnert 19 Aug '12

19 Aug '12

Hi, we have posted a review request for odeint (a library for solving ordinary differential equations) on this list some days ago. An ODE is dx/dt = f(x(t)) and one is looking for the solution x(t) which is a function of t. Solving ODEs is usually an iterative task, so one starts with x(0) and iteratively applies a solver to obtain a discretized (and approximated) representation of the solution: x(0) -> x(dt) -> x(2*dt) -> x(3*dt) -> ... I played around with an iterator which is doing exactly this iterative procedure. For example, it can be used via odeint::runge_kutta4< state_type > stepper; // ode solver std::array< double , 3 > x = {{ 10.0 , 10.0 , 10.0 }}; // initial state double res = std::accumulate( // parameters : solver , ode , state , time , time_step make_const_step_iterator_begin(stepper, lorenz(), x, 0.0, 0.01) , make_const_step_iterator_end( stepper, lorenz(), x, 1.0, 0.01) , 0.0 , []( double sum, const state_type &x) { return sum + x[0]; } ); The first iterator increments the time until the time of the second iterator is rearched t=0.0 -> t=0.01 -> t=0.02 -> .. t=1.0 and the first component of the solution is accumulated. In principle, this approach works quite well, but there are some problems at least semantically. Maybe someone here has some comments or ideas on this: The defintion of this iterator is: template< class Stepper , class System , class StepperTag > class const_step_iterator : public boost::iterator_facade < const_step_iterator< Stepper , System , StepperTag > , typename Stepper::state_type const , boost::single_pass_traversal_tag > { ... }; It is a single pass iterator, so it can only check for equality of two iterators. This is problematic since equality here means that the time (t) of the begin iterator is smaller then the time of the end iterator. To ensure commutativity of the != or == operation I needed to flag the begin and end iterator explicitly. This is the reason for the two factory functions make_const_step_iterator_begin and make_const_step_iterator_end, which are doing this flagging. The second semantically problem is that the end iterator in principle does not need to know the stepper as well as the system (lorenz() in the above example). But all algorithms from the standard library and Boost.Range assume that the begin and end iterator are of same type. Therefore you have to put the stepper and the system into the end iterator too. Of course, there are techniques like type erasure which might solve this problem, but they introduce some run-time overhead which we want to avoid here. Any ideas or comments about this? P.S. The code can be found in the iterator branch in odeint: boost/numeric/odeint/iterator/const_step_iterator.hpp and some examples libs/numeric/odeint/examples/const_step_iterator.cpp git clone -b iterator git@github.com:headmyshoulder/odeint-v2.git

5 19

Request for a typedef for the larger integer type that supports atomic loads and stores.
by Vicente J. Botet Escriba 18 Aug '12

18 Aug '12

Hi, I'm locking for a portable integer type that is the larger integer type that supports atomic loads and stores. The sig_atomic_t type defined in <csignal> supports atomic loads and stores but I'm not sure is the larger one. Does boost define such a typedef? If not, could such typedef be included in boost and where? Best, Vicente

2 1

What to do with platform defining 'null' as preprocessor symbol?
by Jan Hudec 17 Aug '12

17 Aug '12

Hello Folks, At work we develop, among others, for Bada. The system library provided is unfortunately somewhat flaky. A tell-tale sign is, that it's native API headers define lowercase 'null' as preprocessor symbol expanding to 0. Unfortunately boost uses identifier 'null'. So far we only hit the two cases in boost/test/utils/basic_cstring/basic_cstring.hpp, where I fixed it by renaming the symbols in our local copy of that header, but I noticed there are many more instances in other modules. Would it make sense to rename those identifiers and avoid that name like boost avoids 'min' and 'max'? Or perhaps I could try simply undefining it in config/platform somewhere and see whether Bada headers would break? Unfortunately I don't think gcc has ability to redefine macros temporarily to reinstate the original definition at the end of boost. Generally speaking, Bada provides it's own native API, which is different from anything else. It's object-oriented and looks nice at first sight, but sometimes is inflexible in surprising places. It looks like they wrote whatever they needed to implement applications that ship with the phones and stopped there. The platform also provides ANSI C library and some parts of POSIX, but many functions don't really work. Fortunately the platform is going to be merged with Titzen, so it should at least get working POSIX kernel (Linux) and standard libraries. That makes supporting this obscure platform even less worth big trouble. -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

1 0

[general] Endianity detection for ARM
by Jan Hudec 17 Aug '12

17 Aug '12

Hello All, Something in Boost.Test started using detail/endian.hpp internally between 1.43 and 1.50. Since at work I build Boost.Test-based tests for several mobile platforms, all of which use ARM, I needed to fix it. It is easy for all platforms built with either gcc or clang (Android, iOS and Bada). Gcc defines __ARMEB__ for big-endian ARM and __ARMEL__ for little-endian ARM. Windows CE is however another issue. Microsoft usually defines rather characteristic _M_<arch> macros, but _M_ARM is *not* defined in Windows CE, though it appears to be defined for Windows 8 ARM (I don't work with those yet). The WinCE projects define ARM and _ARM_, but those may appear on big-endian ARM platforms too. However since there are no big-endian Win32 platforms and they are unlikely to be created, I suggest just hardcoding little endian for anything that defines _WIN32 (the _M_* macros could then possibly be removed, but they don't cause any problems there). I therefore propose this patch: --- a/boost/detail/endian.hpp +++ b/boost/detail/endian.hpp @@ -57,7 +57,7 @@ || defined(_POWER) || defined(__powerpc__) \ || defined(__ppc__) || defined(__hpux) || defined(__hppa) \ || defined(_MIPSEB) || defined(_POWER) \ - || defined(__s390__) + || defined(__s390__) || defined(__ARMEB__) # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 #elif defined(__i386__) || defined(__alpha__) \ @@ -66,7 +66,9 @@ || defined(_M_ALPHA) || defined(__amd64) \ || defined(__amd64__) || defined(_M_AMD64) \ || defined(__x86_64) || defined(__x86_64__) \ - || defined(_M_X64) || defined(__bfin__) + || defined(_M_X64) || defined(__bfin__) \ + || defined(__ARMEL__) \ + || defined(_WIN32) // ARM Windows CE don't define __ARMEL__ nor _M_ARM, but there are no big-endian Windows versions # define BOOST_LITTLE_ENDIAN # define BOOST_BYTE_ORDER 1234 -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

1 0

Boost.Units does not honor setw width?
by Paul A. Bristow 17 Aug '12

17 Aug '12

> -----Original Message----- > From: Paul A. Bristow [mailto:pbristow@hetp.u-net.com] > Sent: Thursday, August 09, 2012 4:44 PM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] [type_erasure] Review started (July 18-27, 2012) Flushed with success using Steven Watanabe's type_erase for printing columns, I have enjoyed extending it to use a fixed column width. But I have stumbled on a feature of Boost.Units output where Boost.Units does not honor the iostream width fully. This can be seen in this minimal example: std::cout << std::setw(20) << 'm' << std::endl; outputs 19 spaces and 'm', total 20 as expected. quantity<length> ql = 2345.6 * meters; std::cout << std::setw(20) << ql << std::endl; outputs 2345.6 m but the m does not line up with the previous 'm'. There are 14 leading spaces and 5 digits, 1 period and a space and letter m for the unit, a total of 22. The reason is that the first item value() is output using the ios width setting, but the second unit() 'm' (and separating space) is not, as in this line in io.hpp . os << q.value() << ' ' << Unit() I have 'cured' this 'bug' (I suspect it is a feature really) thus in boost/units/io.hpp template<class Char, class Traits, class Unit, class T> inline std::basic_ostream<Char, Traits>& operator<<(std::basic_ostream<Char, Traits>& os, const quantity<Unit, T>& q) { if (units::get_autoprefix(os) == autoprefix_none) { std::streamsize w = os.width(); if (w > 0) { // Need to build a single string with the width specified // (or outputting severally would not honour the width). std::ostringstream oss; oss << q.value() << ' ' << Unit(); os << oss.str(); } else { // No os.width set (so save the time needed to construct an ostringstream?) os << q.value() << ' ' << Unit(); } } This works for no_prefix, giving the expected number of leading spaces. But not for autoprefix - when a similar trick looks to get much more complicated (and when I start to get that 'angels fear to tread' feeling ;-) Of course the jaggedness of the layout becomes clearer both as the units get longer and get auto-prefixes (eg engineering). And there is a similar problem using a User defined Type like the measurement.hpp example in std::ostream& operator<< os << val.value() << "(+/-" << val.uncertainty() << ")"; where the second item is additional to the width, not included in it. 1 But I am not sure if this is wise. Is this a 'feature'? 2 Is this the best way of solving it? 3 Can/how should this be applied to autoprefix? 4 Should submit a ticket for this? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

Review Wizard Status Report for August 2012
by Ronald Garcia 16 Aug '12

16 Aug '12

============================================== Review Wizard Status Report for August 2012 ============================================== News ==== 1. Multiprecision Arithmetic Reviewed 2. Type Erasure Reviewed 3. Boost 1.50.0 Released. New Libraries: 1) Algorithm 2) Functional/OverloadedFunction 3) LocalFunction 4) Utility/IdentityType Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Multiprecision - reviewed June 2012; review manager: Jeffrey Hellrung The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. * Context - accepted January 2012; author: Oliver Kowalke. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. 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, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot 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. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. 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, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Range Extensions * Contract * Nowide (M) * ODEint * Array (M) * TypeIndex (M) ``(M)`` marks libraries that need review managers. -------------------- 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: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :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. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :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 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Contract -------- :Author: Lorenzo Caminiti :Review Manager: Dave Abrahams :Download: http://sourceforge.net/projects/contractpp/files/latest/download :Description: This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. ODEint ------ :Author: Karsten Ahnert and Mario Mulansky :Review Manager: Steven Watanabe :Download: https://github.com/headmyshoulder/odeint-v2 :Description: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. TypeIndex --------- :Author: Antony Polukhin :Review Manager: Needed :Download: https://github.com/apolukhin/type_index :Description: TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

2 2

dramatically improved template error messages (was: C++11 decltype/SFINAE puzzler)
by Eric Niebler 16 Aug '12

16 Aug '12

(Andrew, a specific question for you below...) (Moderators: can you see why this msg from Andrew never reached the list (which he cc'ed))? On 8/14/2012 8:39 AM, Andrew Sutton wrote: >> GCC-4.7 gives a similarly terse error message. This, I think, is what >> I've been looking for. > > That's neat. Bravo! I've refined this idea. It now avoids cascading errors by detecting when a sfinae_error is passed as an argument to another function. (For the Haskell-ers out there, that makes it like the Either monad.) You can also get the full backtrace by uncommenting one line of code. IMO, this is now approaching something of real value. My personal experience using this with Proto-11 is that it dramatically improves error messages. I can also easily imagine how this can be used to implement a very nice concept-checking library for C++11 that approximates auto-concepts. Andrew, any thoughts on this? You've done far more work in this space than I have. I'd also like to know *why* this works, and indeed if it's guaranteed to. In particular, is it guaranteed that the virtual what() member of the sfinae_error class is instantiated at the outermost call site and not elsewhere (thereby eliminating the deep template back-trace)? I really just stumbled on this technique by accident, and I don't know how thin the ice is here. Both clang-trunk and gcc-4.7 think it's ok. (I'd also like to apologize to Paul Fultz for spelling his name wrong in an earlier message.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 8