- Boost-users - lists.boost.org

Boost Review Wizard Report for January 2012
by Ronald Garcia 10 Jan '12

10 Jan '12

============================================== Review Wizard Status Report for January 2012 ============================================== News ==== 1. Type Traits Library Extensions Accepted 2. AutoIndex Tool Accepted 3. Heaps Library Accepted 4. Assign v2 Library Rejected 5. Type Traits Introspection Library Accepted 6. Lockfree Library Accepted 7. Algorithm Library Accepted 8. Atomic Library Accepted 9. Local Library Accepted 10. Context Mini-review Ongoing Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Conversion - reviewed August 2011; review manager: Gordon Woodhull. 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. * Atomic - accepted July 2011; author Helge Bahmann * Lockfree - accepted August 2011; author: Tim Blechmann. * Algorithm - accepted December 2011; author: Marshall Clow The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Heaps - accepted June 2011; author: Tim Blechmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Log - accepted provisionally March 2010; author: Andrey Semashev. * Endian - accepted provisionally November 2011; author: Beman Dawes. After repeated failed attempts to contact the author, the following library has been marked as Orphaned. * Switch library, accepted provisionally January 2008 author: Steven Watanabe. 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 before we do that, 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) * Network (M) * Singularity (M) * Predef (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: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&fil…>`__ | http://www.ddj.com/cpp/205918714 (documentation) :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: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :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: The variadic_macro_data 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: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Network ------- :Author: Dean Michael Berris :Review Manager: Needed :Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ :Description: This is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/icaretaker/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. Predef ------ :Author: Rene Rivera :Review Manager: Needed :Download: http://tinyurl.com/73n6a3k :Description: The Predef library implements two simple tasks: 1. Definition of a single version number macro to provide consistent version number at the preprocessor level. 2. A collection of detected definitions for compilers, standard libraries, architectures, operating systems, and languages. Unlike the Boost Config Library it doesn't define language features and capabilities. But only defines presence of detected compilation context. Documentation and downloads are available in the sandbox.. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

Re: [Boost-users] [Multi Index] equal_range from templated function fails to compile with gcc 4.6.1
by Jacob Metcalfe 10 Jan '12

10 Jan '12

Thanks for the quick reply, 51566 does seem very similar. I do not experience the issue from bug 9810 in any of the compilers where I have managed to reproduce the bug - from a quick look it looks somewhat different - and unfortunately changes to access_specifier.hpp don't solve the issue (changing the inheritance modifier or access modifiers in the derived class also does not seem to help). I experimented with a few changes but the only case that got rid of the error was the obvious change of making node_type public in index_base.hpp. In terms of gcc versions - so far I have reproduced the issue with 4.6.1, 4.6.2 and 4.5.2. Jacob.

2 2

extract objects from vector in shared memory
by Sabine B 09 Jan '12

09 Jan '12

Hello! I have again a question to using the boost vector with shared memory objects. I managed inserting the objects of type "MyType" into the vector with the following code: typedef boost::interprocess::allocator<MyType*, managed_shared_memory::segment_manager> ShmemAllocator; typedef boost::interprocess::vector<MyType*, ShmemAllocator> MyVector; struct shm_remove{ shm_remove(){shared_memory_object::remove("MySharedMemory");} ~shm_remove(){shared_memory_object::remove("MySharedMemory");} }remover; managed_shared_memory segment(create_only, "MySharedMemory", 65536); const ShmemAllocator alloc_inst(segment.get_segment_manager()); MyVector *vector = segment.construct<MyVector>("Vector")(alloc_inst); MyType *mytype = segment.construct<MyType>(anonymous_instance)(); MyVector->push_back(mytype); The problem is that I can't manage to extract the object from the vector. I always get a null pointer or a pointer to somewhere. This is the code for the child process: managed_shared_memory segment(open_only, "MySharedMemory"); vector = segment.find<MyVector>("Vector").first; MyType *mytype = vector->at(1); // program crashes when I try to print members of the object MyType or MyType mytype = (MyType&)vector->at(1); // object is empty Does anybody have any hint or an idea what I'm doing wrong? Thank you very much for your help! Best regards, Sabine

1 0

[Multi Index] equal_range from templated function fails to compile with gcc 4.6.1
by Jacob Metcalfe 09 Jan '12

09 Jan '12

I’m having issues compiling some multi_index_container code after upgrading from gcc 4.3.4 to gcc 4.6.1 and wondering if anyone can shed some light. Perhaps this should be directed to gcc, but I have not been able to reduce this to not include multi_index. The contrived code below is the furthest I have been able to reduce the problem so far:**** ** ** 1 #include <boost/multi_index_container.hpp>**** 2 #include <boost/multi_index/ordered_index.hpp>**** 3 #include <boost/multi_index/member.hpp>**** 4 #include <boost/multi_index/composite_key.hpp>**** 5**** 6 using namespace boost::multi_index;**** 7**** 8 struct Data{**** 9 double _d;**** 10 };**** 11**** 12 typedef multi_index_container< Data,**** 13 indexed_by< ordered_non_unique<**** 14 composite_key< Data, member<Data, double, &Data::_d> >**** 15 > >**** 16 > Map;**** 17**** 18 template <int T>**** 19 void foo(){**** 20 Map mi;**** 21 mi.get<0>().equal_range(boost::make_tuple(0.0));**** 22 }**** 23 int main(){**** 24 foo<5>();**** 25 }**** ** ** The failures from gcc 4.6.1 are:**** ** ** boost/multi_index/detail/index_base.hpp: In function 'void foo() [with int T = 5]':**** boost/multi_index/detail/index_base.hpp:49:47: error: 'typedef struct boost::multi_index::detail::index_node_base<Data, std::allocator<Data> > boost::multi_index::detail::index_base<Data, boost ::multi_index::indexed_by<boost::multi_index::ordered_non_unique<boost ::multi_index::composite_key<Data, boost::multi_index::member<Data, double, &Data::_d> > > >, std::allocator<Data> >::node_type' is protected**** tstmi.cpp:24:10: error: within this context**** ** ** ** ** This code appears to compile fine under 4.3.4 and would compile with 4.6.1 if the useless template at line 18 was removed.**** ** ** Many thanks

2 1

[boost.build] packaging with dependencies symbolic links
by Christophe Bourez 09 Jan '12

09 Jan '12

Hi, I have an executable project depending on other 3rd libraries (log4cplus, libxml2 ...). For each of these 3rd libraries, we recreate the missing Jamroot file. The executable is built (g++ under linux) with <link>shared property. When packaging, no symlinks to 3rd libraries are generated. Investigating boost.build, I found the property <install-no-version-symlinks> (Its default and unique value is 'on'). Is it related? If yes, may I workaround it? How can I package my executable with symlinks to 3rd library ? Thank you, Christophe

1 0

Re: [Boost-users] Needs advices on design ( mpl or processor )
by Alex Perry 07 Jan '12

07 Jan '12

On 07 January 2012 23:28 Alex Perry wrote:- > I've been following this thread despite being a total novice with mpl (and > template meta-programming in general). However I'm not quite sure why > you are trying to pass the offset through the templates in the 1st place - can't > you just use standard : syntax and let the compiler work out the offsets? Oops just read some more messages in the thread and now understand what you were trying to do (which wasn't what I was doing at all) Sorry for the noise Alex

1 0

Re: [Boost-users] Needs advices on design ( mpl or processor )
by Alex Perry 07 Jan '12

07 Jan '12

On Sat 07/01/2012 08:42 Allan Nielsen <a(a)awn.dk> wrote:- >I will try to illustrate my design problem in a more simple example: > >struct TagA { > enum Size { size = 4 }; > enum E { A0 = 0, A1 = 1, A2 = 2, A3 = 3, }; }; > ... I've been following this thread despite being a total novice with mpl (and template meta-programming in general). However I'm not quite sure why you are trying to pass the offset through the templates in the 1st place - can't you just use standard : syntax and let the compiler work out the offsets? Eg enum A { A0,A1,A2,A3,A4 }; enum B { B0,B1,B2,B3,B4 }; template <typename type1, int t1_numbits, typename type2, int t2_numbits> struct packed { type1 first : t1_numbits; type2 second : t2_numbits; }; Obviously accessing members via a name like first is far from ideal and specifying the size in the template would make this really unusable. However at this point my lack of knowledge of mpl kicks in - I'm sure there is some clever way of coding this up so that packed<A,B,C> is defined like mpl::vector<> which could provide a clean way of accessing the members. My total naive first attempt using partial specialisations on member functions sort of works under MSVC but fails totally on gcc - not sure if this is because this is a MS extension or whether its C++11 and so would work on a newer gcc - it works with VS2010 and VS2008 (I don't think there are any C++0x extensions in 2008) on windows 7 and fails to compile with gcc 4.1.2 on Linux. Linux errors start with :- test.cpp:53: error: explicit specialization in non-namespace scope 'struct packed<type1, type2, type3, type4>' test.cpp:53: error: enclosing class templates are not explicitly specialized It's also relying on the (probably nearly always true) assumption that the enum types packed together would always be unique so that using the type of the enum can find the unique member - this assumption should at least have some sort of compile assertion on it (mpl again I guess). It seems like an awful lot of boiler plate code would have to live behind the scenes to make this anything like useable though so not sure its worth exploring as a possible method but just in case it helps :- #include <iostream> //An enum we want to be able to compress enum A{A0,A1,A2,A3,A4}; //The bit size information for enum as per previous example code (NB this is actually wrong 3 is big enough to hold 0-7 but heck ...) struct tagA { typedef enum A enum_type; enum { size=4 }; }; //Wrapper for above tag info just to save typeing having shown it done manually above template <typename enumType,int size_ = 4> struct tag { typedef enumType enum_type; enum { size=size_ }; }; //Another couple of enums and tag structures for bit sizes enum B{B0,B1,B2,B3,B4}; typedef tag<B,4> tagB; enum C{ C0,C1,C2,C3,C4 }; typedef tag<C,3> tagC; //Just to check that size is actually doing something enum D{ D0,D1,D2,D3,D4 }; typedef tag<D,4> tagD; //Our packed structure template <typename type1,typename type2, typename type3, typename type4 > struct packed { //Just for clarity typedef typename type1::enum_type first_type; typedef typename type2::enum_type second_type; typedef typename type3::enum_type third_type; typedef typename type4::enum_type fourth_type; typedef packed<type1,type2,type3,type4> thistype; //Our packed enums using the specified bit sizes first_type first : type1::size; second_type second : type2::size; third_type third : type3::size; fourth_type fourth : type4::size; //All following is just to provide a simple get/set syntax rather than accessing via member names struct fail {}; //Only used for general case - fail will not convert to T hence compile error when used template <typename T> T get() const { return fail; }; //Specialisations to provide access to the (unique) members based on their types template<> first_type get<first_type>() const { return first;} template<> second_type get<second_type>() const { return second;} template<> third_type get<third_type>() const { return third;} template<> fourth_type get<fourth_type>() const { return fourth;} //May as well define == using the get() - note extra specialisation for whole structure equality template <typename T> bool operator == (T const & other ) const { return get<T>() == other; } template <> bool operator ==<thistype>(thistype const & other ) const { return other==get<type1::enum_type>() && other==get<type2::enum_type>() && other==get<type3::enum_type>() && other==get<type4::enum_type>(); } template <typename T> void set(T val) { return fail; }; //Specialisations to provide access to the (unique) members based on their types template<> void set<first_type>(first_type val) { first = val;} template<> void set<second_type>(second_type val) { second = val;} template<> void set<third_type>(third_type val) { third = val;} template<> void set<fourth_type>(fourth_type val) { fourth = val;} //May as well define operator = for convenient syntax l template <typename T> T operator =(T val) { set<T>(val); return val; }; }; //Oh yuk but it would be nice to pass the actual enum names rather than the tag structure name into our template //I couldn't think of any easy way other than a macro but surely there is some neater solution. #define make_packed_type(A,B,C,D) packed<tag##A,tag##B,tag##C,tag##D> int main( int , char** ) { packed<tagA,tagB,tagC,tagD> test; make_packed_type(A,B,C,D) test2; //Try the macro version test.first = A3; //Using the specific member name test.set<B>( B4 ); //Using template specialisation of member function test.set( C1 ); //Same but using ADL test = D3; //ADL on operator = test2 = A3; test2 = B4; test2 = C1; test2 = D3; //Hmm having 2nd thoughts on this syntax - it's probably too confusing and unexpected to allow std::cout << "In test A is " << test.first << " B is " << test.get<B>() << " C is " << test.get<C>() << " D is " << test.get<D>() << std::endl; std::cout << "Sizeof of test is " << sizeof( test ) << std::endl; std::cout << "Piecewise equality check is" << " ==A3 " << ((test == A3)?"true":"false") << " ==B4 " << ((test == B4)?"true":"false") << " ==C1 " << ((test == C1)?"true":"false") << " ==D3 " << ((test == D3)?"true":"false") << std::endl; std::cout << "Overall equality check test == test2 is " << (( test == test2 )?"true":"false") << std::endl; return 0; } Which returns (on windows) In test A is 3 B is 4 C is 1 D is 3 Sizeof of test is 4 Piecewise equality check is ==A3 true ==B4 true ==C1 true ==D3 true Overall equality check test == test2 is true As I said before don't know if this is of any use whatsoever to you (but it allowed me to avoid doing some real work while playing!) - As shown in the output the size of the structure is 4 bytes so is packing the 4 enums down into 1 int (without the : syntax used the sizeof this structure is 16 bytes) Alex

1 0

boost ASIO/serialisation with different boost version. Bug or feature ?
by Avi Bahra 07 Jan '12

07 Jan '12

Currently I have built a client/server that uses ASIO with boost serialization. I built one set with boost 1.45 and another with boost 1.47 However: o start boost 1.45 server o ping using 1.47 client I get a boost::archive::archive_exception unsupported version o start boost 1.47 server o ping with boost 1.45 client Again I get a boost::archive::archive_exception unsupported version Given that there was no change in format of the ping, is this bug or feature ? Is there any way of disabling this feature of the archive , so exception is only thrown when there is format change? Any help appreciated. Ta, Avi

2 1

Register variadic template as tags in a boost::mpl::map
by Allan Nielsen 07 Jan '12

07 Jan '12

In the following code, why can't I look up BB and CC in the mpl::map type_map? I would expect the map to look like this: map < pair<AA, A< xx > >, pair<BB, B< xx > >, pair<CC, C< xx > > > But it does not seem like this is the case... #include <iostream> #include <boost/type_traits/is_same.hpp> #include <boost/mpl/map.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/insert.hpp> struct AA {}; struct BB {}; struct CC {}; template<int OFFSET> struct A { typedef AA T; enum O { offset = OFFSET }; enum S { size = 2 }; }; template<int OFFSET> struct B { typedef AA T; enum O { offset = OFFSET }; enum S { size = 4 }; }; template<int OFFSET> struct C { typedef AA T; enum O { offset = OFFSET }; enum S { size = 4 }; }; template < template <int> class Head, template <int> class... Tail> struct X : public Head< X<Tail...>::size * X<Tail...>::offset >, public X<Tail...> { typedef Head< X<Tail...>::size * X<Tail...>::offset > _Head; enum O { offset = X<Tail...>::size * X<Tail...>::offset }; enum S { size = _Head::size * X<Tail...>::size }; typedef typename boost::mpl::insert < typename X<Tail...>::type_map, boost::mpl::pair<typename _Head::T, _Head > >::type type_map; template <typename T> int get_offset() { return boost::mpl::at<type_map, T>::type:: offset; } }; // base case template < template <int> class Head> struct X<Head> : public Head<1> { enum O { offset = Head<1>::offset }; enum S { size = Head<1>::size }; typedef boost::mpl::map< boost::mpl::pair< typename Head<1>::T, Head<1> > > type_map; }; int main() { X< A, B, C > x1; std::cout << x1.get_offset<CC>() << std::endl; // generates compile errors //std::cout << x1.get_offset<BB>() << std::endl; //std::cout << x1.get_offset<CC>() << std::endl; return 0; }

1 1

[BGL] getting an edge_descriptor of a reverse_graph
by Alex Hagen-Zanker 06 Jan '12

06 Jan '12

I upgraded from boost 1.45 to 1.48 and there are some breaking changes related to reverse_graph The main problem that I encounter is that boost::edge(u ,v, graph) returns a edge_descriptor to the graph that underlies reverse_graph, rather than reverse_graph itself . The following therefore does not compile: template<typename Graph> void foo(Graph& graph) { boost::graph_traits<Graph>::edge_descriptor e = boost::edge(0, 1, graph).first; } int main() { boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS> graph(2); foo(graph); // this line compiles foo(boost::make_reverse_graph(graph)); // this line does not compile } Do you have suggestions how to rewrite foo(Graph& graph) in order to generically work for both plain and reversed graphs? For now I have rewritten the boost::edge function in reverse_graph.hpp to return a pair<reverse_graph_edge_descriptor, bool> but that does not seem right. Thanks, Alex

2 6