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

[test] broken (fails to compile) with boost.timer since 1.48
by Jamie Allsop 13 Jan '14

13 Jan '14

Boost.Test fails to compile since 1.48 when Boost.Timer is included. I find that often I want to use timers when testing. I reported this back in 2012 along with a comprehensive patch that fixes the issue. On the eve of 1.55 I see the patch has still not been applied, despite an original agreement to do so. Unfortunately I don't have commit privileges so I am unable to do this myself. The original discussion from here: http://lists.boost.org/Archives/boost/2012/09/196811.php went as follows: > On 25/09/12 18:14, Gennadiy Rozental wrote: >> Jamie Allsop<ja11sop<at> yahoo.co.uk> writes: >> >>> >>> These are patches we've been using for some time locally, the recent >>> discussions highlighted the importance of pushing patches like these to >>> a wider audience. >>> >>> In summary the key changes are: >>> >>> * https://svn.boost.org/trac/boost/ticket/7410 >>> * https://svn.boost.org/trac/boost/ticket/7397 >> >> These are fine. I'll try to check it in on a weekend > > Excellent thanks! Yet https://svn.boost.org/trac/boost/ticket/7397 was never applied. With changes to Boost.Test since then it is likely that the patch needs modified to be applied but that should not be too hard. Apart from that I'd like to see the suite of 4 patches applied as a whole. So far only https://svn.boost.org/trac/boost/ticket/7410 has been applied but the patches address severe use-case short-comings in Boost.Test that make it viable for broader testing use. I've summaried them below. * https://svn.boost.org/trac/boost/ticket/7397 * https://svn.boost.org/trac/boost/ticket/7410 (applied) * https://svn.boost.org/trac/boost/ticket/7417 (small) * https://svn.boost.org/trac/boost/ticket/7419 (small) Original discussion that didn't really get very far was in these threads: * http://lists.boost.org/Archives/boost/2012/09/196811.php * http://lists.boost.org/Archives/boost/2012/09/196828.php For those who are interested I've pasted my original motivations from the year old thread below as a reminder. Basically the patches allow Boost.Test to: * compile with Boost.Timer (so not broken) * output test progress on the fly in a format other tools could parse * allows Boost.Test to be used for live test diagnostics in running systems in a 'test' mode Jamie * https://svn.boost.org/trac/boost/ticket/7410 (applied) * all test cases/suites have file and line information captured so that external tools can use the Boost.Log output to create links into the source tree, answering questions like, "What is this test case?". It is possible to simply follow the link and see. * https://svn.boost.org/trac/boost/ticket/7417 * update the Boost.Test log output to include summary status information when a test case or suite is completed. This includes the test status, assertions passed and total assertions. This allows live test status to be viewed and nicer tools to be built around this. For example each test can be shown starting, in progress and then complete with the resulting status in detail. I should note that Boost.Test reports currently output this additional test status but this is done only on *completion of all tests* and so *cannot* be used to show live progress. * this additional test status as part of the log can be easily captured using regular expressions if HRF is used and many IDEs will allow colourisation, autolinking and so on using similar approaches. * https://svn.boost.org/trac/boost/ticket/7397 * update Boost.Test to use the new Boost.Timer classes introduced in Boost 1.48. This can be suppressed through the use of a macro should the old timers be preferred. The new Boost.Timer provides much better timing information than the old Boost.Timer library. You should refer to the library itself for an explanation of why the previous timer library was deprecated: http://www.boost.org/doc/libs/1_51_0/libs/timer/doc/index.html * https://svn.boost.org/trac/boost/ticket/7419 Essentially the patch does two things: * It allows boost::unit_test_framework::init() to be called more than once. The result is to reset the test status and master test suite so that new tests can be added and new reports generated through multiple calls. The CLA parsing is also reset. Recent changes to this code may make my call to clear() redundant. I'll let Gennadiy be the judge of that. * This first change then allows the framework setup and teardown to be encapsulated in a helper class (not provided in the patch but one could be). In our systems we use a helper class that exposes a simple API that allows the user to implement a method where test units can be added directly to the master test suite - see the ticket for an example. As I said the patch focuses solely on enabling the possibility of writing such a class, not the class itself. * It provides scoped Boost.Test arguments for the commandline when BOOST_TEST_USE_QUALIFIED_COMMANDLINE_ARGUMENTS is defined. All command line arguments are then called --boost.test.<argument> for example --boost.test.log_level instead of --log_level. This of course means that all Boost.Test related arguments will not clash with any program arguments. On its own this is a generally useful feature as it allows custom main() functions to pass arguments down to other components during simple unit testing.

2 1

[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

[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

[Container] Priority Deque - Refinement
by Nathaniel McClatchey 19 Dec '13

19 Dec '13

Hi. I've recently made a double-ended priority queue (priority deque) publicly available at https://github.com/nmcclatchey/Priority-Deque , with the intent of submitting it to Boost (more specifically, I wish to make it part of Boost.Container). I would appreciate any comments, discussion, or refinements. Goals of the project: * Provide an efficient double-ended priority queue, with interface similar to std::priority_queue. * Keep requirements to a minimum. In particular, require nothing except what is already required by std::priority_queue. * Make it fast. Performance should be competitive with std::priority_queue. How goals are met: * The priority deque is implemented as a single class template, mimicking std::priority_queue * The interface of priority_deque is a strict superset of the interface of std::priority_queue. New functions follow the STL naming scheme. * The underlying container is assumed to be a sequence container supporting random-access iterators, front(), back(), and push_back(), as in std::priority_queue. No other assumptions are made. * The underlying data structure is an interval heap, which allows finding min/max in O(1) time, and single-element changes in O(log n) time. * Benchmarks (on queues with 20,000,000+ elements) indicated that the difference in performance between std::priority_queue and the priority deque is negligible when compiled by GCC with the O3 option. A specific question for anyone more experienced with development of generalized code: * I added several functions for controlled access to arbitrary elements. Is this overkill? If so, should they be removed? Thank-you for your time, Nate

7 16

[filesystem] fix recur_dir_itr_imp::increment(system::error_code* ec) in 1.54.0
by claudio.bley＠gmail.com 19 Dec '13

19 Dec '13

Hi. What's happening to the filesystem library? It seems there's no progress on any tickets in the bug tracker? Referring to https://svn.boost.org/trac/boost/ticket/6821#comment:5 Could we get this fix into 1.54.0, please? BTW, sorry for any confusion - I "managed" to comment on the wrong ticket... https://svn.boost.org/trac/boost/ticket/5403 would've been more appropriate, I guess. Claudio -- Claudio

3 4

RFC: edit_distance / edit_alignment library
by Erik Erlandson 18 Dec '13

18 Dec '13

Boost Community, I cooked up a library that provides a pair of functions: edit_distance() and edit_alignment(). The library currently lives here: https://github.com/erikerlandson/edit_distance Some short example programs are here: https://github.com/erikerlandson/edit_distance/tree/master/examples A few example expressions: // the edit distance (aka levenshtein distance) unsigned dist = edit_distance("abc", "bcd"); // using a custom cost function for insertion, deletion, substitution unsigned dist = edit_distance("abc", "bcd", custom_cost_function()); // accepts arbitrary sequences, ranges, range adaptors unsigned dist = edit_distance(as_vector("abc"), as_list("bcd") | boost::adaptors::reversed); // obtain the edit distance and the list of the edit operation codes (in output iterator) unsigned dist = edit_alignment("abc", "bcd", std::ostream_iterator<edit_opcode>(std::cout, "")).second; // adaptors to add edit operation costs and sequence elements to the edit operation output unsigned dist = acquire<elements>(acquire<costs>(edit_alignment))("abc", "bcd", std::ostream_iterator<boost::tuple<edit_opcode, unsigned, char, char> >(std::cout, "")).second; I'm interested in community feedback on whether these would be a useful addition to boost::algorithms. I envision these as the first additions to an eventually-larger library of other kinds of string distances, dynamic programming, and other algorithms for sequence alignment.

4 17

Any interest in a framework for memoization?
by Giacomo Drago 14 Dec '13

14 Dec '13

Hi, I would like to submit a small framework for memoization I am working on (http://projects.giacomodrago.com/c++memo/) At the moment, it is still in a beta stage and does not comply with Boost guidelines. I would like to know if you might be interested. The idea is to have a tool for rapid prototyping of software components implementing dynamic programming algorithms or, anyhow, requiring memoization. I paste here a simple "fibonacci" example: ---------------------- int fibonacci(int i, std::function<int(int)> prereqs) { if (i == 0) return 0; if (i <= 2) return 1; return prereqs(i-1) + prereqs(i-2); } cppmemo::CppMemo<int, int> cppMemo; std::cout << cppMemo.getValue(30, fibonacci) << std::endl; ---------------------- The code will print 832040, without recursive calls to the "fibonacci" function. A stack is managed "under the hood" and appropriate calls are made to the "fibonacci" callback to gather pre-requirements and then call the function again when they are available. This is just a toy example. There is more to know about, including important caveats (if you are interested, please read the documentation carefully): some defaults for template and method parameters are useful for conciseness but are EVIL if you don't know about them. The framework also provides automatic parallelization (when possible). It is important to remark that at this moment the framework relies on fcmm (fast concurrent memoization map), a custom hashmap that is optimized for this very purpose. This can be changed quite easily, as fcmm is not exposed to the client. A C++11 compliant compiler is needed. Thanks for your attention. Giacomo

3 6

[build] Default compiler options for a toolset
by Edward Diener 10 Dec '13

10 Dec '13

How are the default compiler options for a toolset chosen ? Is it in the .jam file for the compiler toolset and, if so, where is it specified ?

6 35

BOOST_NO_CXX11_ATOMIC?
by Peter Dimov 04 Dec '13

04 Dec '13

Now is perhaps not a very appropriate time to ask, but why don't we seem to have a macro for the <atomic> C++11 header?

6 13