- Boost - lists.boost.org

[predef] [rfc] Mutually exclusive definitions?
by Rene Rivera 13 Jan '14

13 Jan '14

After going back and re-reading various commentaries for the review of Boost.Predef and some after the review I'm questioning a design choice of Boost.Predef. Currently Boost.Predef will define multiple symbols when, for example, a compiler "emulates" another compiler. The current common occurrence of this is the GCC compiler which many other compilers emulate by defining the GCC version macros. This is no longer the case for the OS definitions though. The OS definitions are mutually exclusive. And hence in order to make for a more consistent behavior I am considering changing the library to make not just OS defs mutually exclusive. But also making compiler, library, and architecture mutually exclusive. And I'm asking for some general feedback as to what the most useful approach, from using Boost.Predef, is likely to be. In particular I'm considering the following choices: 1. Simple mutual exclusion of BOOST_ARCH_*, BOOST_COMP_*, BOOST_LIB_C_*, BOOST_LIB_STD_*, and of course BOOST_OS_* definitions. 2. Mutual exclusion of the base/real definitions with the addition of *_EMULATED definitions when multiple defs detected. For example for GCC we would have BOOST_COMP_GCC_EMULATED indicated the version of the GCC being emulated. 3. No mutual exclusion of base definitions but with the addition of a "flag" definition when multiple defs are detected. For example with GCC it would have the usual BOOST_COMP_GCC but also have a "#define BOOST_COMP_GCC_IS_EMULATED". 4. Do nothing and live with multiple definitions and the current discrepancy in behavior for BOOST_OS definitions. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[TypeTraits] propose new callable-type call traits
by Hui Li 13 Jan '14

13 Jan '14

I've implemented a few traits classes (code attached below) that, for a given callable-type T, and a set of Args..., detects whether the function call T::operator()(Args...) would be (1) valid, (2) ambiguous, or (3) none is viable. where T is allowed to have arbitrary overloaded operator()'s. This could be useful for programmers who want to (1) make the function call only when it's valid, (2) generate customized error/warning messages when it's ambiguous, or handle/redirect it without getting an ambiguous compiler error, and (3) redirect non-viable calls to some default behavior, which can be different than how it's handled when the call is ambiguous. If people are interested, I suppose this could be a useful addition to TypeTraits. I would appreciate any feedback! For clarity, the implementation and demonstration attached below is written in c++11. It can be easily ported to c++98/03 compilers by using TypeTratis to replace the std type traits, BOOST_TYPEOF_KEYWORD to replace decltype, and Boost.Preprocessor to generate code for arbitrary arity. - Hui Li #include <utility> #include <type_traits> template < typename T > struct is_callable; template < typename Signature > struct has_valid_call; template < typename Signature > struct has_ambiguous_call; template < typename Signature > struct has_no_viable_call; template < typename T > struct is_callable { struct yes {}; struct no {}; struct ambiguate_seed { void operator()(); }; template < typename U, bool=std::is_class<U>::value > struct ambiguate : U, ambiguate_seed {}; template < typename U > struct ambiguate<U,false> : ambiguate_seed {}; template < typename U, typename = decltype(&U::operator()) > static constexpr no test(int); template < typename > static constexpr yes test(...); static bool constexpr value = std::is_same<decltype(test< ambiguate<T> >(0)),yes>::value ; typedef std::integral_constant<bool,value> type; }; template < typename T, typename... Args > struct has_valid_call< T(Args...) > { struct yes {}; struct no {}; template < typename U, bool = is_callable<U>::value > struct impl { template < typename V, typename = typename std::result_of<V(Args...)>::type > struct test_result { using type = yes; }; template < typename V > static constexpr typename test_result<V>::type test(int); template < typename > static constexpr no test(...); static constexpr bool value = std::is_same<decltype(test<U>(0)),yes>::value; using type = std::integral_constant<bool, value>; }; template < typename U > struct impl<U,false> : std::false_type {}; static constexpr bool value = impl<T>::value; using type = std::integral_constant<bool, value>; }; template < typename T, typename... Args > struct has_ambiguous_call< T(Args...) > { struct ambiguate_seed { void operator()(...); }; template < class U, bool = is_callable<U>::value > struct ambiguate : U, ambiguate_seed { using ambiguate_seed::operator(); using U::operator(); }; template < class U > struct ambiguate<U,false> : ambiguate_seed {}; static constexpr bool value = not has_valid_call< ambiguate<T>(Args...) >::value; using type = std::integral_constant<bool, value>; }; template < typename T, typename... Args > struct has_no_viable_call< T(Args...) > : std::integral_constant<bool, not (has_valid_call<T(Args...)>::value or has_ambiguous_call<T(Args...)>::value)> {}; #include <string> #include <vector> struct test { void operator()(int); void operator()(double); void operator()(int,double); template < typename T > typename std::enable_if< not std::is_integral<T>::value >::type operator()(const T&, int=0){} template < typename T > typename std::enable_if< std::is_integral<T>::value >::type operator()(const std::vector<T>&, T*){} template < typename T > int operator()(const std::string&, int){} }; int main(int argc, const char * argv[]) { static_assert( is_callable<test>::value , ""); static_assert( not is_callable<int>::value , ""); static_assert( has_valid_call<test(char const*,long)>::value , ""); static_assert( has_valid_call<test(std::string&,long)>::value , ""); static_assert( has_valid_call<test(std::vector<int>, int*)>::value , ""); static_assert( has_no_viable_call<test(std::vector<double>, double*)>::value , ""); static_assert( has_valid_call<test(int)>::value , ""); static_assert( has_valid_call<test(int,double)>::value , ""); static_assert( not has_valid_call<test(int,double,int)>::value , ""); static_assert( not has_ambiguous_call<test(double)>::value , ""); static_assert( has_ambiguous_call<test(unsigned)>::value , ""); static_assert( not has_no_viable_call<test(unsigned)>::value , ""); static_assert( not has_no_viable_call<test(int)>::value , ""); static_assert( has_no_viable_call<test(void)>::value , ""); return 0; }

5 16

[Macro]Test Case grouping using Traits
by Hemanth Choudary M V (RBEI/ETA1) 13 Jan '14

13 Jan '14

Hello, I have observed that in native unit test framework(c++), there is an option to group test cases using attributes which are reflected as traits in the Test Explorer window in MS VS2012. Following is a an example of the same: BEGIN_TEST_METHOD_ATTRIBUTE(TestMethod3) TEST_OWNER(L"SuperMan") TEST_PRIORITY(2) TEST_METHOD_ATTRIBUTE(L"Category",L"Slow") END_TEST_METHOD_ATTRIBUTE() TEST_METHOD(TestMethod3) { Assert::AreEqual(2,6); } How can this be achieved via Boost Unit Test Library? Are there macros to achieve the same? Mit freundlichen Grüßen / Best Regards, Hemanth Choudary MV RBEI/ETA1

2 1

[Test] Problems with debug::break_memory_alloc
by Fredrik Orderud 13 Jan '14

13 Jan '14

I have a problem with the memory-leak detection logic in boost.test. What happens when unit_test::framework::init starts up on Windows is that memory-leak detection is first explicitly activated. Secondly, debug::break_memory_alloc is called with a value (default is 1). Activation of leak detection is great, but to always override the allocation number to break on is not necessary a good idea if the user has already set a value from a debugger. In my case I am investigating a leak from a static member allocated prior to main and/or boost.test being invoked. In that case, I need to break the program early to be able to set the allocation number to break on. This works well by itself, but it's _very_ confusing when boost.test afterwards replaces my allocation number with a default value. Could it be possible to modify boost.test, so that it only modifies the allocation number to break on if the user has explicitly requested to break on a given allocation? Thanks in advance, Fredrik Orderud

2 4

[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

Boost unit test with BOOST_NO_EXCEPTIONS
by driscoll 13 Jan '14

13 Jan '14

I work on a team that uses compiles with exception support disabled. (That... is not my decision, and no value judgments on that, please. :-)) I'd kind of like to use the unit test library. However, at a surface level it has lots of uses of raw try/catch/throw instead of BOOST_TRY/BOOST_CATCH/BOOST_THROW. At a deeper level, I suspect what's doing is throwing an exception on an EXPECT or ASSERT failure -- and thus that disabling exceptions will basically mean that a test failure will cause an immediate abort in the program. (I guess I can hack around that in an ugly but somewhat-reasonable way.) How hopeless is using the library with BOOST_NO_EXCEPTIONS? Evan

3 2

(no subject)
by Gly Marvellou 13 Jan '14

13 Jan '14

Hi, I'm a CS major and new to this list. I want to contribute to Boost C++ libraries under GSOC 14. Can someone guide me through? Gly

1 0

Data-Structures, Ideas. GSoC 2014
by Ankit Vadehra 12 Jan '14

12 Jan '14

Hi, I'm Ankit Vadehra, and i was contacting to ask whether Boost is considering participation in GSoC 2014, and if it is, then are there some new ideas of some priority Data Structures Classes that are to be introduced in Boost ?? For Example, previously have worked on Trie Data Structure as well as Boom Filters and so on, but none of these advanced data-structures were merged in the main library, anyways.. Anyways, are there any new ideas?? GSoC, ain't that far away now, and Idea Page is till not up.. ?? Is someone working on it, by any chance ? Thanks.! -- Ankit.Vadehra "The Code Is free, But its Priceless" "Exactly, which way is Forward ?"

1 0

[trac] where is david_abrahams?
by Eric Niebler 11 Jan '14

11 Jan '14

Dave is still listed as the primary maintainer of several libraries, but Trac won't let me assign a new bug to him. "david_abrahams" isn't one of the choices in the Owner drop down. Where'd he go? -- Eric Niebler Boost.org http://www.boost.org

2 2

[multi_index][ann] Boost.MultiIndex 1.56 preview: major update with new hashed index implementation
by Joaquín Mª López Muñoz 11 Jan '14

11 Jan '14

Hi, Those interested can already download the preview of Boost.MultiIndex as it'll be shipped in Boost 1.56: https://github.com/boostorg/multi_index/archive/master.zip Full release notes can be read at https://rawgithub.com/boostorg/multi_index/master/doc/release_notes.html#bo… The most important change is a complete reimplementation of the internals of hashed indices, so that erasure of elements is constant-time regardless of the level of occupancy of the internal bucket array (previously, performance degraded as the bucket was being depleted.) A full description of the new data structure as compared with other popular implementations of unordered associative containers is given at: http://bannalia.blogspot.com/2013/10/implementation-of-c-unordered.html http://bannalia.blogspot.com/2013/10/implementation-of-c-unordered_25.html Along with some performance results: http://bannalia.blogspot.com/2013/11/measuring-insertion-times-for-c.html http://bannalia.blogspot.com/2013/11/measuring-insertion-times-for-c_16.html http://bannalia.blogspot.com/2013/11/measuring-erasure-times-for-c-unordere… http://bannalia.blogspot.com/2013/11/measuring-lookup-times-for-c-unordered… The new data structure has been thoroughly tested but some pre-shipping feedback is always welcome, so if you test this please report back. Thank you, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

3 5