December 2013 - Boost - lists.preview.boost.org

[test] still broken in release
by Tim Blechmann 30 Dec '13

30 Dec '13

hi all, i've reported an issue before that boost.test in the release branch is pretty broken. *all* tests of the boost.heap testsuite segfault like this: --Program received signal SIGSEGV, Segmentation fault. 0x00000000005f4975 in boost::unit_test::test_suite::add (this=0x8cefa0, tu=0x9, expected_failures=0, timeout=0) at ../../../boost/test/impl/unit_test_suite.ipp:139 139 m_members.push_back( tu->p_id ); (gdb) bt #0 0x00000000005f4975 in boost::unit_test::test_suite::add (this=0x8cefa0, tu=0x9, expected_failures=0, timeout=0) at ../../../boost/test/impl/unit_test_suite.ipp:139 #1 0x00000000005fda9c in boost::unit_test::ut_detail::test_init_caller::operator() (this=0x8d4e08) at ../../../boost/test/impl/framework.ipp:96 #2 0x00000000006031a2 in boost::unit_test::ut_detail::invoker<int>::invoke<boost::unit_test::ut_detail::test_init_caller> (this=0x7fffffffc36f, f=...) at ../../../boost/test/utils/callback.hpp:42 #3 0x0000000000603071 in boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::ut_detail::test_init_caller>::invoke (this=0x8d4e00) at ../../../boost/test/utils/callback.hpp:89 #4 0x000000000060e03d in boost::unit_test::callback0<int>::operator() (this=0x7fffffffcfc0) at ../../../boost/test/utils/callback.hpp:118 #5 0x000000000060de8a in boost::detail::do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (tr=..., F=...) at ../../../boost/test/impl/execution_monitor.ipp:281 #6 0x000000000060d1a8 in boost::execution_monitor::catch_signals (this=0x7fffffffcfd0, F=...) at ../../../boost/test/impl/execution_monitor.ipp:885 #7 0x000000000060d262 in boost::execution_monitor::execute (this=0x7fffffffcfd0, F=...) at ../../../boost/test/impl/execution_monitor.ipp:1211 #8 0x00007ffff7b0bf33 in boost::unit_test::framework::init (init_func=0x4e3f30 <init_unit_test()>, argc=1, argv=0x7fffffffd198) at ../../../boost/test/impl/framework.ipp:268 #9 0x00007ffff7b22267 in boost::unit_test::unit_test_main (init_func=0x4e3f30 <init_unit_test()>, argc=1, argv=0x7fffffffd198) at ../../../boost/test/impl/unit_test_main.ipp:177 #10 0x00000000004e3f62 in main (argc=1, argv=0x7fffffffd198) at ../../../boost/test/unit_test.hpp:59 -- boost.test in trunk works fine, though ... i wonder, will it eventually be merged to release? tim

7 28

[test] Interest in 'hamcrest'-style checks?
by Jared Grubb 29 Dec '13

29 Dec '13

I recently read "Modern C++ Programming with Test-Driven Development", and I really enjoyed this book and highly recommend it. One of the styles I saw for the first time was "hamcrest"-style assertions. ("Hamcrest" is an anagram of "matchers"; also see http://en.wikipedia.org/wiki/Hamcrest.) For a quick idea, imagine there is a BOOST_CHECK_THAT macro that looks like this: (excuse my choice of names here, we can pick better ones if people like the idea) BOOST_CHECK_THAT( str, IsEqualTo(expStr) ); BOOST_CHECK_THAT( str, HasSubstring(needleStr) ); BOOST_CHECK_THAT( str, Not(HasSubstring(badStr)) ); BOOST_CHECK_THAT( vec, Contains(42) ); Comparing them to current boost::test assertions, usually the two are directly equivalent, and it's just a matter of style. At first, I was unconvinced of a need for this. However, there are a few scenarios where the hamcrest-style actually are really helpful: BOOST_CHECK_THAT(vec, Any(Contains(42), Contains(-42)) ); BOOST_CHECK_THAT(str, All(StartsWith("abc"), HasSubstring("lmnop"), EndsWith("xyz")) ); BOOST_CHECK_THAT(count, All(GE(0), LT(10)) ); BOOST_CHECK_THAT(vec, HasSubsequence(otherVec) ); BOOST_CHECK_THAT(vec, Sorted(IsEqualTo({1, 2, 3})) ); BOOST_CHECK_THAT(optionalStr, Any(IsEqualTo(boost::none), Deref(IsEqualTo("str"))); Sure, almost all of this is already doable: BOOST_CHECK_EQUAL_COLLECTIONS( /* sorry, but I really dislike this one :) */ ); BOOST_CHECK( std::count(vec.begin(), vec.end(), 42) && std::count(vec.begin(), vec.end(), -42) ); And, yes, you can create a helper functors today: BOOST_CHECK( Contains(vec, 42) && Contains(vec, -42) ); But hamcrest still gives these advantages over even that: * Dont repeat yourself: -- the value under test appears only once in the check expression; this is really helpful if you want to test an expression ("future.get()") that can only be called once * Better diagnostics: -- when something fails, you can get a detailed error (eg: "blah does not contain the element blah" or "str does not start with blah") -- when you have "Any" conditions, "errors" get squashed if some other condition passes, but all are shown if none pass -- composed tests can provide nested diagnostics; eg: for All(A, Any(B,C)), you'd get something like "'...A...' is true, but none of { '...B...' , '...C...' } are true", but spread over many lines -- and even with indentation if we want * Intentional Asymmetry: Is it BOOST_CHECK_EQ(expected, actual) or (actual, expected)? It really doesnt matter in the end, but a message like "expected 34, got 33" is actually kinda nice. Putting the value under test at the start creates an asymmetry that helps guide the user to put the values in the "right" order. * Composability * Extendibility: once the facility is there, its actually really easy to write more ("CanLockMySemaphoreType(timeout)") I wasnt able to find any discussion on boost's list for this, so I thought I'd bring it up. As for difficulty, implementing the examples above is actually already quite easy using boost::test predicates, and the extra macro would be fairly simple to implement. Almost all the work would be in creating the library of matchers, which is the fun part :) What do you think? Jared

5 11

[TortoiseGit] Screen shots becoming available + submodule update bug
by Beman Dawes 29 Dec '13

29 Dec '13

I've started to post screen shots of TortoiseGit performing the various operations described in "Getting Started with Modular Boost Library Maintenance". See https://svn.boost.org/trac/boost/wiki/TortoiseGitLibMaint Since each screen shot takes a bit of time and effort, I'd like to hear the opinions from some from TortoiseGit users as to whether or not the screen shots seem worthwhile. I particularly wanted to get a screen shot of a submodule update, but hit a bug in TG's "Submodule update...". It was reported yesterday, and the TG folks have already identified the problem as a bug in a library named libgit2, and reported that to the libgit2 folks, citing the boost super-project as the test case. The libgit2 folks have already created a pull request with a patch, so let's hope the fix reaches us reasonably soon. --Beman

2 1

[boost.test] Correct usage?
by Philip Bennefall 29 Dec '13

29 Dec '13

Hello, I just started writing unit tests for a large project that I am involved in, and boost.test has been absolutely fantastic to work with so far. True the documentation could be clearer, but as far as functionality I am very much impressed with the library. I have a question though. I read the following: http://lists.boost.org/Archives/boost/2011/10/186439.php This concerns me. What is the status here? When I build boost_1_54_0, in my stage/lib directory I see: libboost_test_exec_monitor-vc100-mt-s-1_54.lib My test cases look as follows: #define BOOST_TEST_MODULE MyProgram #include <boost/test/unit_test.hpp> BOOST_FIXTURE_TEST_SUITE(basic_operations, basic_memory_logger) BOOST_AUTO_TEST_CASE( some_test ) { // ... // Using BOOST_REQUIRE_EQUAL, BOOST_CHECK_EQUAL, BOOST_CHECK, BOOST_REQUIRE_EQUAL_COLLECTIONS and friends here. } BOOST_AUTO_TEST_SUITE_END() My questions are: 1. Are all these macros still supported and not depricated? 2. Is the structure correct? Am I depending on something depricated? Am I including the right header? I am linking with the library mentioned above (via auto-linking), which is why I am concerned about deprication. Thanks in advance for any clarification on this. Kind regards, Philip Bennefall

3 2

[phoenix] how do i achieve this type of extension of phoenix
by Hui Li 28 Dec '13

28 Dec '13

I want to extend the phoenix library with my own expressions in a specific way. Would appreciate any help!! Thanks! The code below is what i want to achieve, with the intended behavior specified in the comments. The goal is to first build an expression (the expr0), and later bind some value to certain nodes and turn them into different types of nodes with internal states (expr1) but preserve the structure of the expression tree, and also be able to modify the internal states of those nodes. My question is, how to define myplus, mymult, myinit, and myreset to make it work? using boost::phoenix::arg_names::arg1; using boost::phoenix::arg_names::arg2; using boost::phoenix::arg_names::arg3; // how should i define myplus, mymult and myinit, so that // expr1 is arg1 + myplus_f<double>(3.0)(1,arg2) + mymult_f<double>(3.0)(2,arg3) auto expr0 = arg1 + myplus(1,arg2) + mymult(2,arg3); auto expr1 = myinit( expr0, 3.0 ); // evaluate expr1 with actual arguments double r = expr1(1,2,3); // modify the internally held values of myplus_f<double>(3.0) and mymult_f<double>(3.0) // so that expr1 becomes equivalent to arg1 + myplus_f<double>(5.0)(1,arg2) + mymult_f<double>(5.0)(2,arg3) myreset(expr1, 5.0); // evaluate with new value members of myplus_f and mymult_f double r2 = expr1(1,2,3); myplus_f and mymult_f are defined as follows: template < typename T > struct myplus_f { T value; explicit myplus_f(const T& v):value(v){} void reset(const T& new_value) { value = new_value; } template < typename Lhs, typename Rhs > auto operator()(const Lhs& lhs, const Rhs& rhs) const -> decltype(value+lhs+rhs) { return value + lhs + rhs; } }; template < typename T > struct mymult_f { T value; explicit mymult_f(const T& v):value(v){} void reset(const T& new_value) { value = new_value; } template < typename Lhs, typename Rhs > auto operator()(const Lhs& lhs, const Rhs& rhs) const -> decltype(value*lhs*rhs) { return value * lhs * rhs; } };

2 1

Getting Started with Modular Boost Library Maintenance
by Beman Dawes 27 Dec '13

27 Dec '13

I've been pecking away at "Getting Started with Modular Boost Library Maintenance". See https://svn.boost.org/trac/boost/wiki/StartModMaint I'd appreciate comments and corrections. One of the questions that came up was how to number releases for individual libraries. Say Boost.System wants to do a release before the next full Boost release ships. What do I call it? How do I document it? How do I tag it? Strawman proposal ------------------------ * Call it "Boost.System 1.55.1 Point Release". * Document it via the "readme" file that GitHub pesters you to add. Contents would give the title of the release and the release notes. * Create a gh-pages branch with the same release notice. * Tag it 1.55.1 Comments? --Beman

11 26

[Config] Failure with Clang-3.4 in C++14 mode
by Ben Pope 27 Dec '13

27 Dec '13

"clang++-3.4" -c -x c++ -std=c++1y -stdlib=libc++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/config/test/config_test.test/clang-linux-3.4~c14_libc++/debug/config_test.o" "../libs/config/test/config_test.cpp" In file included from ../libs/config/test/config_test.cpp:76: ../libs/config/test/boost_no_constexpr.ipp:37:3: error: no viable conversion from 'const boost_no_cxx11_constexpr::A' to 'int' X<a> xx; // OK: unique conversion to int ^ ../libs/config/test/boost_no_constexpr.ipp:27:14: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_constexpr::A', but method is not marked const constexpr operator int() { return val; } ^ ../libs/config/test/boost_no_constexpr.ipp:28:14: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_constexpr::A', but method is not marked const constexpr operator long() { return 43; } ^ In file included from ../libs/config/test/config_test.cpp:231: ../libs/config/test/boost_no_cxx11_user_lit.ipp:64:15: error: invalid operands to binary expression ('const boost_no_cxx11_user_defined_literals::my_literal' and 'boost_no_cxx11_user_defined_literals::my_literal') return ((a == my_literal(0x23)) && (b == my_literal(9))) ? 0 : 1; ~ ^ ~~~~~~~~~~~~~~~~ ../libs/config/test/boost_no_cxx11_user_lit.ipp:22:19: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_user_defined_literals::my_literal', but method is not marked const constexpr bool operator==(const my_literal& a) { return val == a.val; } ^ ../libs/config/test/boost_no_cxx11_user_lit.ipp:64:42: error: invalid operands to binary expression ('const boost_no_cxx11_user_defined_literals::my_literal' and 'boost_no_cxx11_user_defined_literals::my_literal') return ((a == my_literal(0x23)) && (b == my_literal(9))) ? 0 : 1; ~ ^ ~~~~~~~~~~~~~ ../libs/config/test/boost_no_cxx11_user_lit.ipp:22:19: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_user_defined_literals::my_literal', but method is not marked const constexpr bool operator==(const my_literal& a) { return val == a.val; } ^ ^ 6 warnings and 3 errors generated. Looks like a simple fix of marking the members const. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3598.html http://www.boost.org/development/tests/trunk/developer/output/BP%20x86_64%2… Ben

2 2

[boostbook] Unsupported doc elements.
by Mostafa 27 Dec '13

27 Dec '13

I was perusing Robert Ramey's very informative blincubator.com when I ran across this: "Though BoostBook specifies a large collection of tags to characterize documentation elements, the large majority of these are not used by Boost library documentation It seems that that they've been included in the hopes of being available for future use. This would be OK except for the fact that the attaching all these tags to one's documentation would be a huge job - which would yield no benefit with the current document preparation system. It's not clear from the BoostBook documentation which tags are used/useful and which should not be bothered with. This leaves one with questions about under what circumstances each tag should be used." Is the situation involving unsupported documentation elements still true? If so, can someone knowledgeable with the issue in the least identify which elements are supported and which are not? Any clarification appreciated, Mostafa

2 1

[PATCH Boost.smart_ptr] Add intrusive_ptr<>::release()
by Avi Kivity 26 Dec '13

26 Dec '13

This provides a way to escape from automatic reference counting, and taking manual control of the reference. Useful when interfacing to a C API that expects a pointer with an elevated reference count. Similar to std::unique_ptr<>::release(). --- include/boost/smart_ptr/intrusive_ptr.hpp | 7 +++++++ intrusive_ptr.html | 23 ++++++++++++++++++----- test/intrusive_ptr_test.cpp | 7 +++++++ 3 files changed, 32 insertions(+), 5 deletions(-) diff --git a/include/boost/smart_ptr/intrusive_ptr.hpp b/include/boost/smart_ptr/intrusive_ptr.hpp index a855a10..8c73fe2 100644 --- a/include/boost/smart_ptr/intrusive_ptr.hpp +++ b/include/boost/smart_ptr/intrusive_ptr.hpp @@ -151,6 +151,13 @@ public: return px; } + T * release() BOOST_NOEXCEPT + { + T * ret = px; + px = 0; + return ret; + } + T & operator*() const { BOOST_ASSERT( px != 0 ); diff --git a/intrusive_ptr.html b/intrusive_ptr.html index 562d27a..ef6238b 100644 --- a/intrusive_ptr.html +++ b/intrusive_ptr.html @@ -71,6 +71,7 @@ T & <A href="#indirection" >operator*</A>() const; // never throws T * <A href="#indirection" >operator-></A>() const; // never throws T * <A href="#get" >get</A>() const; // never throws + T * <A href="#release" >release</A>(); // never throws operator <A href="#conversions" >unspecified-bool-type</A>() const; // never throws @@ -174,11 +175,23 @@ intrusive_ptr & operator=(T * r);</pre> Throws: nothing. </blockquote> <h3><a name="get">get</a></h3> - <pre>T * get() const; // never throws</pre> - <blockquote> - Returns: the stored pointer. - Throws: nothing. - </blockquote> + <pre>T * get() const; // never throws</pre> + <blockquote> + Returns: the stored pointer. + Throws: nothing. + </blockquote> + <h3><a name="release">release</a></h3> + <pre>T * release(); // never throws</pre> + <blockquote> + Returns: the stored pointer. + Throws: nothing. + Postconditions: <code>get() == 0</code>. + Notes: The returned pointer has an elevated reference count. This + allows conversion of an intrusive_ptr back to a raw pointer, + without the performance overhead of acquiring and dropping an extra + reference. It can be viewed as the complement of the + non-reference-incrementing constructor. + </blockquote> <h3><a name="conversions">conversions</a></h3> <pre>operator unspecified-bool-type () const; // never throws</pre> <blockquote> diff --git a/test/intrusive_ptr_test.cpp b/test/intrusive_ptr_test.cpp index 614a9cb..90248fe 100644 --- a/test/intrusive_ptr_test.cpp +++ b/test/intrusive_ptr_test.cpp @@ -330,6 +330,13 @@ void test() BOOST_TEST(get_pointer(px) == px.get()); } + + { + boost::intrusive_ptr<X> px(new X); + X* released = px.release(); + BOOST_TEST(released->use_count() == 1); + delete released; + } } } // namespace n_access -- 1.8.3.1

7 15

Project for developing Binary Indexed Tree
by Arpit Mittal 26 Dec '13

26 Dec '13

Hi All, I am new to the group. I am interested to know that if developing a Binary Indexed Tree for Boost C++ will be a good project. Thanks and Regards Arpit Mittal

1 0