- Boost - lists.boost.org

Regression tests crashing
by Tom Kent 03 Apr '13

03 Apr '13

Sometime yesterday most of the regression tests that I run (not the incremental ones?) started crashing and not sending any results. The screen output is the general error: "No such file or directory: '/home/tomkent/teeks99-02/a/results/boost/bin.v2/libs/any/test/any_test.test'" Looking at the tail of the results/bjam.log file shows this: error: at /home/tomkent/teeks99-02/a/tools_bb/kernel/modules.jam:107 error: Unable to find file or target named error: 'has_float128.cpp' error: referred to from project at error: '../libs/multiprecision/config' That was on Ubuntu 12.04, running the gcc-4.6 tests, but the others (including windows) have the same error. I don't believe anything else changed on the machines that were running the regression tests. You can still see the previous results on the regression results page. Tom Kent

1 0

[utility]result_of - erroneous result type from a C++11 lambda
by Vicente J. Botet Escriba 03 Apr '13

03 Apr '13

Hi, I've started to use C++11 lambda functions with Boost.Thread. The following works with clang-3.2 boost::future<int> f1 = boost::async( []() -> int {return 123;} ); But it fails with gcc-4.6.2, 4.7.2 and 4.8.0 ../example/lambda_future.cpp:25:91: erreur: conversion from ‘boost::future<void>’ to non-scalar type ‘boost::future<int>’ requested boost::future<int> f1 = boost::async( []() -> int {return 123;} ); The current implementation of boost::async uses boost::result_of to get the result type of the callable parameter. Is this a know bug on boost::result_of or gcc compiler? Best, Vicente

9 15

generate algorithm
by Fabian Bösch 02 Apr '13

02 Apr '13

Dear Boost community I am developing a library which extends the STL generate algorithm. It's aim is to improve performance for highly optimized (e.g. vectorized) generation mechanisms while it retains the same interface. This is especially useful when dealing with random number generation as there are several libraries (e.g. Intel MKL or AMD ACML) which provide means to generate a block of random values at once. However, the current STL generate algorithm is not able to cope with such "range generation". Is there any interest in a such a library for Boost? Cheers, Fabian Bösch

4 5

[boost.lockfree] Lockfree on Windows?
by Philip Bennefall 02 Apr '13

02 Apr '13

Hello, I am in need of a lock free fifo for my current project so I looked into lockfree. However, in the documentation I see: boost.lockfree has been tested on the following platforms: a.. g++ 4.4, 4.5 and 4.6, linux, x86 & x86_64 b.. clang++ 3.0, linux, x86 & x86_64 My question is what the status is on Windows? The documentation for boost.atomic says that Windows has been tested, so is there a reason why lockfree might have platform specific issues? When I run the example provided for the single producer/single consumer queue, I get the expected results so it does seem to work. It also states that the queue is lock free. Is it safe to use on Windows at present? Thanks in advance for any information. Kind regards, Philip Bennefall

2 3

[extension] library under construction status
by Lorenzo Caminiti 02 Apr '13

02 Apr '13

Hello all, What's the status of Jeremy Pack's library under construction Boost.Extension? P.S. I read the docs and I have a couple of comments: 1. shared_library as RAII Why isn't shared_library an RAII object? If there's a good reason for that, a RAII object should also be provided scoped_library that will open at construction and automatically close at destruction. 2. get should use function type syntax get<result_type, arg1_type, arg2_type, ...> should be changed to get<result_type (arg1_type, arg2_type, ...)> 3. type_map purpose/name The introduction of type_map seems arbitrary... some rationale needs to be provided as soon as it's introduced in Tutorial 2. Is there a better name than type_map? That name tells me little about what it is.. maybe, factory_map given that it's a map strings to factories? 4. call(type_map) lib.call(type_map) the name call is too generic, it should be changed to set or even better get_factories: type_map types; if(!lib.call(types)) ... Changed to: factory_map factories; if(!lib.get_factories(factories)) ... 5. type_map doesn't allow for multiple constructors type_map doesn't allow for derived classes to have constructors with different signatures than the base class. It also doesn't allow for classes (derived or base) to have multiple constructors. In any case, the syntax should use member function types, changing the current syntax: std::map<std::string, factory<animal, int> >... to: std::map<std::string, factory<void (*::animal)(int)> 6. I didn't understand parameter_map purpose, usage, etc :( Thanks. --Lorenzo

3 3

Building ThreadPool with boost::function in boost::lockfree::queue
by Ryan Fogarty 01 Apr '13

01 Apr '13

I am having trouble typedef-ing a lockfree::queue with boost::function as the element for a ThreadPool class I am writing. TestJobQueue1 below compiles fine while TestJobQueue2 compile fails. I am using gcc 4.7.2 and boost_1_53_0. void doSomething() { std::cout << "Called doSomething\n"; } typedef boost::function<void ()> FunctionType; class TestJobQueue1 { public: typedef std::vector<FunctionType> FunctionArray; TestJobQueue1() { std::cout << sizeof(FunctionType) << std::endl; FunctionType f(&doSomething); FunctionArray funcArray; funcArray.push_back(f); std::cout << funcArray.size() << std::endl; } }; class TestJobQueue2 { public: typedef boost::lockfree::queue<FunctionType> QueueType; TestJobQueue2() { std::cout << sizeof(FunctionType) << std::endl; FunctionType f(&doSomething); QueueType funcQueue; funcQueue.push(f); } }; >> g++ -c -I/usr/local/boost_1_53_0/include TestFunctionCompleteness.cpp produces: In file included from TestFunctionCompleteness.cpp:11:0: /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp: In instantiation of ‘class boost::lockfree::queue<boost::function<void()> >’: TestFunctionCompleteness.cpp:42:17: required from here /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:79:1: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’ /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:83:1: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’ >> g++ -c --std=c++0x -I/usr/local/boost_1_53_0/include TestFunctionCompleteness.cpp produces: In file included from TestFunctionCompleteness.cpp:11:0: /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp: In instantiation of ‘class boost::lockfree::queue<boost::function<void()> >’: TestFunctionCompleteness.cpp:42:17: required from here /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:79:5: error: static assertion failed: (boost::has_trivial_destructor<T>::value) /usr/local/boost_1_53_0/include/boost/lockfree/queue.hpp:83:5: error: static assertion failed: (boost::has_trivial_assign<T>::value) Is boost::function somehow an incomplete type and not expected to work in boost::lockfree::queue or is this a bug in the queue implementation? Can anyone suggest a simple workaround? Thank you, Ryan Fogarty

2 3

traits classes vs. metafunctions
by Stefan Strasser 01 Apr '13

01 Apr '13

Hi everyone, are there any guidelines for boost libraries on when to use traits classes and when to use a metafunction for each member of a would-be traits class? I've seen both in boost libraries. c++11 uses traits classes (iterator_traits, pointer traits, ...), but Abrahams and Gurtovoy [1] argue that traits classes ("traits blobs") should be avoided "at all costs" because they are an unnecessary concatenation of multiple metafunctions into one metafunction with multiple return values. in practice, this means that if a single 'traits class member' aka 'metafunction result' ought to differ from the defaults, the entire traits class has to be reimplemented by the user, not only the metafunction whose result ought to differ from the default. on the other hand, asking a user to implement 5 or more metafunctions is much more tedious than implementing a traits class. possibility 1) template<...> struct property1 : mpl::bool_<...>{}; template<...> struct property2 : mpl::bool_<...>{}; template<...> struct property3 : mpl::bool_<...>{}; 2) template<...> struct ..._traits{ typedef mpl::bool_<...> property1; typedef mpl::bool_<...> property2; typedef mpl::bool_<...> property3; }; you could provide both, but in which "direction"? does a traits class refer to metafunctions, or do metafunctions refer to a traits class? a) template<...> struct ..._traits{ typedef typename property1<...>::type property1; typedef typename property2<...>::type property2; typedef typename property3<...>::type property3; }; b) template<...> struct property1 : ..._traits<...>::property1{} template<...> struct property2 : ..._traits<...>::property2{} template<...> struct property3 : ..._traits<...>::property3{} which is accessed when "calling" the metafunction? it seems to me that metafunctions are better for the "caller" and traits classes are better for the implementor of the traits/metafunctions. in my case, the caller is a library and the implementor is the user, so you might choose a traits class over metafunctions. but what if a new member is added that wasn't there before (like "property4"). the implementor of an (old) traits class could not have known about the new member, so accessing the new member (by the library) will result in an error, while a new metafunction "property4" could simply return a default. should new properties of traits classes only be accessed after making sure they exist, using SFINAE? there isn't a precedent for this in c++11. only new traits classes were introduced, but no new members of already existing traits classes. should metafunctions always be preferred? why did c++11 choose traits classes over metafunctions, even though the concept of a metafunction was introduced in c++11 (<type_traits>). Thanks [1] Abrahams; Gurtovoy: C++ Template Metaprogramming, 2.2 Metafunctions

7 14

[config] gcc-4.8 and __GXX_EXPERIMENTAL_CXX0X__
by Vicente J. Botet Escriba 01 Apr '13

01 Apr '13

Hi, it seems that gcc-4.8 doesn't defines any more __GXX_EXPERIMENTAL_CXX0X__ when the flag -std=c++11 is given. This means that all the BOOST_NO_CXX11_ are defined. Could something be done to make usable gcc-4.8 in c++11 mode? Best, Vicente

2 4

[mpi] Boost.MPI and MPI 3!
by Renato Forti 01 Apr '13

01 Apr '13

Hi All, Boost.MPI project will support MPI version 3 with that provide some support to fault tolerance! Have any work in this area? Thanks

2 2

[build & test] clang-3.2 for Win32
by Jim Bell 01 Apr '13

01 Apr '13

I took the liberty to run regressions with clang-3.2 on Win32. It's pretty unhappy, and most failures have to do with it not building shared libraries (DLLs) correctly. Not finding symbols. I found a (non-boost) thread that talks about that being a problem with it. Even so, I had a couple questions: 1. It gets labeled clang-linux-3.2, though it's under the Windows umbrella in the regression matrix. How do we fix that? user-config.jam 'using clang ;' does seem to work fine. 2. I get these warnings. They seem like clang's problem, not ours. Am I right? ..\boost/test/execution_monitor.hpp:59:7: warning: 'dllexport' attribute only applies to variables and functions [-Wignored-attributes] class BOOST_TEST_DECL translate_exception_base { ..\boost/test/detail/config.hpp:88:29: note: expanded from macro 'BOOST_TEST_DECL' # define BOOST_TEST_DECL BOOST_SYMBOL_EXPORT ..\boost/config/platform/win32.hpp:30:42: note: expanded from macro 'BOOST_SYMBOL_EXPORT' # define BOOST_SYMBOL_EXPORT __declspec(dllexport) <built-in>:154:38: note: expanded from macro '__declspec' #define __declspec(a) __attribute__((a)) 3. I tried to coerce the regression to use only static libraries (since clang does build boost static pretty well)... --bjam-options='link=static runtime-link=static' but this made some part of the regression tests very unhappy: error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use That's understandable, as it goes against the grain. But is there a way to inform the tests somehow? It's easy to imagine wanting to explicitly test what a shared library does, but what about cases where it doesn't matter if it's shard or static? (Are they distinguishable?) If anyone's interested, please peruse the mess I made of the regression matrix. And purge them from the matrix, too, eventually.

1 0