- Boost - lists.boost.org

Boost Build and Test
by Robert Ramey 17 May '16

17 May '16

I started a new thread to accommodate the widening discussion on CMake. Build and Test systems: I've always been a big complainer about Boost Build. Now I'm a big complainer about CMake as well. Just so you know. I always found it weird that the buiding of libraries jam file was stashed in it's own directory - build while jam files for other components like test and building docs was found inside their respective directories. I also added to the serialization library some other jam files in subdirectories example and in performance. So to me by far the most natural place to find the library jam file would be in the directory we've agreed to name src. I never made any issue of this as my whole progress through life is about moving on to get my own projects done. Largely motivated by the desire to do cutting edge C++ development I replaced my old windows system with a mac mini. Soon I wanted to build and test my projects in XCode IDE. I like to use an IDE, but setting it and maintaining it for a project like the serialization library is an incredible amount of work. So I resolved to setup CMake to do the job. I had exposure to CMake before and found it no better than all the other build systems. But it needed to do what I wanted it to do - create the IDE project and it was very popular. So I managed to make it work in this context and the result has been quite satisfactory. But making it run all the tests I want to run - different compilers, libraries, etc. etc. integrating with my own library_status dashboard builder looked like a serious pain and I already had an elaborate Jamfile set for doing all of that. So upshot is I use them both for different purposes. I don't see anything wrong with that. In order not to upset the established structure I put my CMakeLists.txt file inside it's own directory. If it was totally up to me, what I'd like to see is: a) jam files in the build directory moved to src b) thereby acknowledging the practice of having jam files in the same directories which contain the build sources. c) which is pretty much the same as the CMake approach. c) official tolerance for including other build systems at the same level such as CMakeLists.txt and maybe MS projects and solutions. d) official tolerence for including a top level CMakeLists.txt. Personally I don't think this is necessary or even a good idea - but I want to leave that as a separate discussion. Robert Ramey

1 0

Final benchmark graphs for Colony vs std:: containers now available
by Soul Studios 17 May '16

17 May '16

Re-wrote my benchmark code from scratch a month or two ago with some help from Baptiste Wiche, have run over std::list, std::map, std::multiset, std::deque, std::vector, and for GCC, Chris's segmented_tree implementation. To be honest there's not much point comparing against segmented_tree, as the goals are totally different (efficient random access insertion for segtree, vs efficient unordered erasure/insertion/iteration without pointer invalidation colony), but there was some interest last time I wrote here. In addition I compared against other methods for ensuring pointer/index validity using deques and vectors, to see how those things pan out. Graphs are available here: http://www.plflib.org/colony.htm#benchmarks and here: http://www.plflib.org/stack.htm There are also MSVC 2013 results linked to in the first paragraph of the benchmarks. Comments are welcome, but please read the page first. Stack performs particularly well, outperforming all alternatives in both GCC/MSVC.

3 16

Boost ICL tests attempting to pass non-bidirectional iterator to std::reverse_copy
by Billy O'Neal (VC LIBS) 16 May '16

16 May '16

Hi folks. I'm not a Boost.ICL expert, but we detected this one failure with our in-development STL and this test case: template <ICL_IntervalSet_TEMPLATE(_T) IntervalSet, class T> void interval_set_element_iter_4_discrete_types() { typedef IntervalSet<T> IntervalSetT; typedef typename IntervalSetT::interval_type IntervalT; typedef std::vector<T> VectorT; IntervalSetT set_a; set_a.add(I_I(1,3)).add(I_I(6,7)); VectorT vec(5), cev(5); vec[0]=MK_v(1);vec[1]=MK_v(2);vec[2]=MK_v(3);vec[3]=MK_v(6);vec[4]=MK_v(7); cev[0]=MK_v(7);cev[1]=MK_v(6);cev[2]=MK_v(3);cev[3]=MK_v(2);cev[4]=MK_v(1); VectorT dest; std::copy(elements_begin(set_a), elements_end(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( vec == dest, true ); dest.clear(); std::copy(elements_rbegin(set_a), elements_rend(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( cev == dest, true ); dest.clear(); std::reverse_copy(elements_begin(set_a), elements_end(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( cev == dest, true ); dest.clear(); std::reverse_copy(elements_rbegin(set_a), elements_rend(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( vec == dest, true ); } which produces this failure: C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1672): error C2665: 'std::_Reverse_copy1': none of the 2 overloads could convert all the argument types C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1655): note: could be '_OutIt std::_Reverse_copy1<_Iter,_OutIt>(_BidIt,_BidIt,_OutIt,std::random_access_iterator_tag,std::random_access_iterator_tag)' with [ _OutIt=std::back_insert_iterator<VectorT>, _Iter=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>>, _BidIt=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>> ] C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1645): note: or '_OutIt std::_Reverse_copy1<_Iter,_OutIt>(_BidIt,_BidIt,_OutIt,std::bidirectional_iterator_tag,std::_Any_tag)' with [ _OutIt=std::back_insert_iterator<VectorT>, _Iter=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>>, _BidIt=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>> ] C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1672): note: while trying to match the argument list '(boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<DomainT,Compare>>>>>, boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<DomainT,Compare>>>>>, std::back_insert_iterator<VectorT>, boost::iterators::detail::iterator_category_with_traversal<std::input_iterator_tag,Traversal>, std::output_iterator_tag)' with [ DomainT=bicremental_type_5, Compare=std::less ] and [ DomainT=bicremental_type_5, Compare=std::less ] and [ Traversal=boost::iterators::bidirectional_traversal_tag ] c:\dev\wcfb01_01\src\qa\vc\fe\3rdpartycomp\boost_1_60_0\libs\icl\test\fastest_interval_set_\../test_interval_set_shared.hpp(810): note: see reference to function template instantiation '_OutIt std::reverse_copy<boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<DomainT,Compare>>>>>,std::back_insert_iterator<VectorT>>(_BidIt,_BidIt,_OutIt)' being compiled with [ _OutIt=std::back_insert_iterator<VectorT>, DomainT=bicremental_type_5, Compare=std::less, _BidIt=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>> ] c:\dev\wcfb01_01\src\qa\vc\fe\3rdpartycomp\boost_1_60_0\libs\icl\test\fastest_interval_set_\../fastest_interval_set_cases.hpp(61): note: see reference to function template instantiation 'void interval_set_element_iter_4_discrete_types<boost::icl::interval_set,discrete_type_2>(void)' being compiled We are considering reverting this enforcement of iterator category tag in our STL, but technically a standard library appears within its rights to reject this. Billy Robert O'Neal III SDE II - Visual C++ Libraries bion(a)microsoft.com

1 0

media file errors
by Rainer Deyke 15 May '16

15 May '16

"CDs/Reverend Bizarre - III - So Long Suckers (disc 1)" is redundant and should be deleted. In "CDs/Shadow Gallery - Room V": "Shadow Gallery - Seven Seas.mp3" -> "Shadow Gallery - Seven Years.mp3" -- Rainer Deyke (rainerd(a)eldwood.com)

1 0

Call for Submissions: International Conference on Information Society (i-Society 2016), Technical Co-Sponsored by IEEE UK/RI Chapter!
by Faye Bewsy 13 May '16

13 May '16

1 0

[proto][variant] variant crashes proto expression
by Igor R 13 May '16

13 May '16

The following code is a slightly modified Proto calc2 example. Instead of doubles I use variant<int, double>, and the expression is just _1 = _2. This code triggers assertion in variant/detail/forced_return.hpp, so it looks like some variant instance gets messed up. It happens when the value returned from proto::eval(*this, ctx) is being copied. It can be reproduced both with MSVC and gcc, with Boost 1.60. Is there any workaround for this issue? Thanks. ////////////// #include <iostream> #include <boost/proto/proto_typeof.hpp> #include <boost/proto/core.hpp> #include <boost/proto/context.hpp> #include <boost/variant.hpp> namespace proto = boost::proto; using proto::_; typedef boost::variant<int, double> var_t; template<typename Expr> struct calculator_expression; // Tell proto how to generate expressions in the calculator_domain struct calculator_domain : proto::domain<proto::generator<calculator_expression> > {}; // Will be used to define the placeholders _1 and _2 template<int I> struct placeholder {}; // Define a calculator context, for evaluating arithmetic expressions // (This is as before, in calc1.cpp) struct calculator_context : proto::callable_context< calculator_context const > { // The values bound to the placeholders var_t d[2]; // The result of evaluating arithmetic expressions typedef var_t result_type; explicit calculator_context(const var_t &d1 = var_t(), const var_t &d2 = var_t()) { d[0] = d1; d[1] = d2; } // Handle the evaluation of the placeholder terminals template<int I> result_type operator ()(proto::tag::terminal, placeholder<I>) const { return d[ I - 1 ]; } }; // Wrap all calculator expressions in this type, which defines // operator () to evaluate the expression. template<typename Expr> struct calculator_expression : proto::extends<Expr, calculator_expression<Expr>, calculator_domain> { explicit calculator_expression(Expr const &expr = Expr()) : calculator_expression::proto_extends(expr) {} BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression<Expr>) // Override operator () to evaluate the expression var_t operator ()() const { calculator_context const ctx; return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1) const { calculator_context const ctx(d1); return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1, const var_t &d2) const { calculator_context const ctx(d1, d2); return proto::eval(*this, ctx); } }; // Define some placeholders (notice they're wrapped in calculator_expression<>) calculator_expression<proto::terminal< placeholder< 1 > >::type> const _1; calculator_expression<proto::terminal< placeholder< 2 > >::type> const _2; // Now, our arithmetic expressions are immediately executable function objects: int main() { BOOST_PROTO_AUTO(expr, _1 = _2); var_t a1(1), a2(2.5); expr(a1, a2); return 0; }

3 2

[intrusive] crash with slist push_back
by Arpan Sen 12 May '16

12 May '16

Hi Boost Dev, Please consider the following code, this crashes with slist but works just fine if I replace slist with list. Also flat_map crashes but std::map works fine. Am I doing something gross or is there a bug here? #include <iostream> #include <boost/container/flat_map.hpp> #include <map> //#include <boost/intrusive/list.hpp> #include <boost/intrusive/slist.hpp> using namespace boost::intrusive; struct m : public slist_base_hook<> { int n; public: m(int k) : n(k) { } }; int main() { boost::container::flat_map<int, slist<m, cache_last<true> > > c1; std::map<int, slist<m, cache_last<true> > > c2; m* m1 = new m(22); c1[1].push_back(*m1); m* tt = new m(99); c2[1].push_back(*tt); } Regards Arpan

2 1

Using thread_local with Boost.Thread
by Ruediger Berlich 11 May '16

11 May '16

Hi there, I am curious whether it would be possible to use C++11 thread_local instead of Boost's own TLS, while continuing to use Boost.Thread ? I assume that there will be problems if Boost falls back to native pthread ? Kind Regards, Beet

1 0

Boost 1.61.0 Release Candidate 2
by Vladimir Prus 11 May '16

11 May '16

The second release candidates for the 1.61.0 release are now available at: http://boost.cowic.de/rc/boost_1_61_0_rc2.zip http://boost.cowic.de/rc/boost_1_61_0_rc2.7z http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.gz The SHA256 checksums are as follows: fa1c34862b7ba8674ed6e064a14667a11830c6252f702d9458451834b74f7815 boost_1_61_0_rc2.7z a547bd06c2fd9a71ba1d169d9cf0339da7ebf4753849a8f7d6fdb8feee99b640 boost_1_61_0_rc2.tar.bz2 a77c7cc660ec02704c6884fbb20c552d52d60a18f26573c9cee0788bf00ed7e6 boost_1_61_0_rc2.tar.gz 02d420e6908016d4ac74dfc712eec7d9616a7fc0da78b0a1b5b937536b2e01e8 boost_1_61_0_rc2.zip The changes relative to RC1 are MSVC fixes for signals2 and graph libraries. 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. The signed list of checksums is also attached, signed with the following key: https://pgp.mit.edu/pks/lookup?op=get&search=0xDA472E8659753BA4 Key fingerprint C5F0 F367 AA66 616F B839 806E DA47 2E86 5975 3BA4 Thanks! -- The release managers

9 14

[lockfree] _ENABLE_ATOMIC_ALIGNMENT_FIX for VS 2015 Update 2
by Stephan T. Lavavej 11 May '16

11 May '16

Hi, While running Boost.Lockfree's tests, one of our compiler devs encountered the following failure: freelist_test.cpp c:\wcfb01\binaries\x86chk\inc\atomic(659): error C2338: You've instantiated std::atomic<T> with sizeof(T) equal to 2/4/8 and alignof(T) < sizeof(T). Before VS 2015 Update 2, this would have misbehaved at runtime. VS 2015 Update 2 was fixed to handle this correctly, but the fix inherently changes layout and breaks binary compatibility. Please define _ENABLE_ATOMIC_ALIGNMENT_FIX to acknowledge that you understand this, and that everything you're linking has been compiled with VS 2015 Update 2 (or later). c:\wcfb01\binaries\x86chk\inc\atomic(669): note: see reference to class template instantiation 'std::_Atomic_base<_Ty,4>' being compiled with [ _Ty=boost::lockfree::detail::tagged_index ] e:\boost\boost\boost\lockfree\detail\freelist.hpp(608): note: see reference to class template instantiation 'std::atomic<boost::lockfree::detail::tagged_index>' being compiled e:\boost\boost\boost\lockfree\detail\freelist.hpp(609): note: see reference to class template instantiation 'boost::lockfree::detail::fixed_size_freelist<T,NodeStorage>' being compiled call "C:\WCFB01\binaries\x86chk\bin\i386\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\bin.v2\libs\lockfree\test\freelist_test.test\msvc-latest\debug\threading-multi\freelist_test.obj.rsp" ...failed compile-c-c++ ..\bin.v2\libs\lockfree\test\freelist_test.test\msvc-latest\debug\threading-multi\freelist_test.obj... with the following type: class tagged_index { public: typedef boost::uint16_t tag_t; typedef boost::uint16_t index_t; protected: index_t index; tag_t tag; }; This is by design - your tagged_index has align 2, size 4, triggering the need for my atomic alignment fix. As the static_assert advises, your code needs to define _ENABLE_ATOMIC_ALIGNMENT_FIX in order to pass. If this has already been fixed in 1.61.0, then that's great (I haven't checked). Thanks, STL

5 14