- Boost - lists.preview.boost.org

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

Associative container using a vector
by Stefan Strasser 01 Apr '13

01 Apr '13

Hi everyone, I often find myself using a specific data structure and I'm wondering whether: - it has a wellknown name - there is a generic equivalent in a boost library - or there is interest to add one. The basic idea is that you have a bunch of values stored in one object of type A: struct A{ vector<Value> values; }; and then you have multiple objects of type B that each have to associate data with each value stored in A. you could use: struct B{ map<Value,Data> data; }; but since A::values already provides a contiguous index for the values you can just as well store the data in B in a vector with matching indexes, and make sure that the indexes used in A::values don't change: struct A{ vector<Value> values; vector<std::size_t> freelist; map<Value,std::size_t> index; void erase(...){ push index of unused value to freelist; } void push_back(Value){ reuse a freelist entry or values.push_back; } }; struct B{ vector<optional<Data> > data; }; keep in mind that there is one object A for many objects B. you can now access the associated data of many objects B by looking up the index once in object A, and by wasting some space in B::data for unused entries: b.data[a.index[value]] If Data is a pointer or any other type that knows an empty() state, you can also get rid of optional<> and generalize it as two template like: template<class Value> class index; template<class Mapped,class OptionalTraits=boost_optional_traits> class vector_map; Is there anything like that?

3 4

[config] BOOST_NOEXCEPT on MSVC
by Michael Marcin 01 Apr '13

01 Apr '13

Why isn't BOOST_NOEXCEPT defined to be throw() for msvc? Microsoft Visual Studio 11.0\VC\include\yvals.h defines: #define _NOEXCEPT throw () and the rest of the standard library implementation uses it ex. void swap(thread& _Other) _NOEXCEPT { // swap with _Other _STD swap(_Thr, _Other._Thr); } http://msdn.microsoft.com/en-us/library/wfa0edys.aspx states: throw() The function does not throw an exception. However, if an exception is thrown out of a function marked throw(), the Visual C++ compiler will not call unexpected (see unexpected (CRT) and unexpected (<exception>) for more information). If a function is marked with throw(), the Visual C++ compiler will assume that the function does not throw C++ exceptions and generate code accordingly. Due to code optimizations that might be performed by the C++ compiler (based on the assumption that the function does not throw any C++ exceptions) if a function does throw an exception, the program may not execute correctly. It seems a better choice here than expanding BOOST_NOEXCEPT to nothing.

2 1

Re: [boost] [fusion] What do we do with nil ?
by Enrique Nieloud 31 Mar '13

31 Mar '13

Hi!, Sorry to bother, but is is patch officially included in version 1.53.0? I'm having trouble to compile under XCode 4 and it seems related to the "nil" word. thanks, - Enrique

1 0

Re: [boost] Review managers wanted for augmented data structures
by Dave Abrahams 31 Mar '13

31 Mar '13

on Mon Mar 04 2013, Vadim Stadnik <vadimstdk-AT-gmail.com> wrote: > On Mon, Mar 4, 2013 at 7:35 PM, Stefan Strasser <strasser(a)uni-bremen.de>wrote: > >> Am 04.03.2013 08:48, schrieb Martin Knoblauch Revuelta: >> >> Do you mean that you would declare them RandomAccess iterators? >>> >>> We can expect to have containers with millions of elements. For that >>> size, O(log N) is about 20 times faster than O(log N log N). That >>> makes a big difference. >>> >> >> isn't that a reason for providing optimized specializations of some STL >> algorithms, instead of introducing another iterator category? >> >> how would a new iterator category even help? >> as long as your iterator is a forward iterator, the user is allowed to >> call std::binary_search on your iterator, which uses the same algorithm on >> any iterator category. (only functions used by binary_search like >> std::advance are specialized on the category) >> where in all this would your tree-optimized binary_search code be called? >> >> the standard doesn't require random access iterator ops to be constant >> time. >> >> > Unfortunately, there is a problem of iterator categories with augmented > trees. The C++ standard specifies computational complexity for iterator > operations, although they are not shown in tables, since all of them are > required to be constant time. In both C++03 and C++11 this is formulated in > the section 24.1.8. Are you sure these iterators don't fall under the *amortized* constant time requirements, just like those of the ordered associative containers? -- Dave Abrahams

2 3

[gil] undocumented/unintended concept requirements in color_convert
by Michael Marcin 31 Mar '13

31 Mar '13

I was trying to add other color spaces support and noticed that the rgb to cmyk converter contains: typedef typename channel_type<P2>::type T2; T2 x = channel_traits<T2>::max_value()-get_color(dst,black_t()); if (x>0.0001f) { float x1 = channel_traits<T2>::max_value()/float(x); T2 should model: http://www.boost.org/doc/libs/1_53_0/libs/gil/doc/html/g_i_l_0264.html but this code additionally requires T2 to be greater-than comparable to float and convertible to float.

3 4