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

[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

[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

[git] Some headers are executable
by Andrey Semashev 08 Jan '14

08 Jan '14

Hi, I've just checked out git and ran b2 headers and noticed that some headers have executable attribute. For example: $ find boost -executable -type f boost/pointee.hpp boost/assign.hpp boost/graph/vf2_sub_graph_iso.hpp boost/indirect_reference.hpp boost/parameter.hpp boost/detail/indirect_traits.hpp boost/detail/is_xxx.hpp boost/range.hpp This was not the case with svn. Is this the result of the transition? Can this be fixed?

2 4

Proposed patch for Ticket #8250
by Borja Miñano 07 Jan '14

07 Jan '14

Good afternoon, I have proposed a patch for Ticket #8250 that is attached in the trac system. As I am new, I post to inform to take it into account for following versions. Hope this could help. -- Un saludo, Borja Miñano IAC3 - Universitat de les Illes Balears Mateu Orfila Building. Office F-213. Cra. Valldemossa km. 7,5 E-07122 Palma de Mallorca. Balears. Spain. Phone: +34 971 173 000 ext. 1318

4 3

[timer] conflict between tools/inspect and libs/timer
by Peter A. Bigot 06 Jan '14

06 Jan '14

A recent merge to master libs/timer includes support for inspect in the test suite, but the invocation requires support for a search-root argument in inspect. That support is not present in tools/inspect's master branch, causing the libs/timer tests to fail. The following process could help detect inter-module dependencies like this: * Initiate your workspace with the superproject checked out on branch master and all modules on the resulting commit (ignore branches). * Checkout the develop branch only for the module(s) you're working on. * Use "git submodule summary" at the superproject level to determine how your workspace differs from what would be expected in the master branch. If multiple modules show changes, there's a risk of coupling, and it might not be appropriate to push any of them to their master branch. * Use "git submodule update" to reset things when switching development between modules. Peter

6 16

Removing _1 from the global namespace (again)
by Peter Dimov 04 Jan '14

04 Jan '14

If we're going to call the next release 2.0, we'll be allowed some latitude with respect to breaking changes, so maybe this is the right time to finally remove the Bind placeholders from the global namespace. This will, however, break many things all around Boost (to say nothing about the outside world), as a quick grep can readily reveal. And, consequently, it will generate a certain amount of work for the maintainers of the affected libraries that, from their point of view, can appear unnecessary. So I'll need a certain amount of community consensus before going ahead and breaking everyone's code. :-)

14 15

[git] mode and whitespace changes remaining between develop and master
by Nathan Ridge 04 Jan '14

04 Jan '14

Hello, I am trying to follow the instructions for "Establishing a merge point after SVN Conversion" [1] for the Boost.Range library. After cherry-picking all the commits to develop that have not been merged to master, onto master (all locally, I have not pushed anything yet), I am finding that there are still some mode and whitespace differences between master and develop (see the diff at the bottom of the message). I cannot find the commits that are responsible for these changes - is it safe to just ignore them? Thanks, Nate [1] https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint diff --git a/include/boost/range.hpp b/include/boost/range.hpp old mode 100755 new mode 100644 diff --git a/include/boost/range/adaptor/strided.hpp b/include/boost/range/adaptor/strided.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/adaptor/transformed.hpp b/include/boost/range/adaptor/transformed.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/algorithm_ext/is_sorted.hpp b/include/boost/range/algorithm_ext/is_sorted.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/detail/demote_iterator_traversal_tag.hpp b/include/boost/range/detail/demote_iterator_traversal_tag.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/detail/implementation_help.hpp b/include/boost/range/detail/implementation_help.hpp old mode 100644 new mode 100755 index 1f7d163..ca12fa4 --- a/include/boost/range/detail/implementation_help.hpp +++ b/include/boost/range/detail/implementation_help.hpp @@ -21,13 +21,13 @@ #include <wchar.h> #endif -namespace boost +namespace boost { namespace range_detail { template <typename T> inline void boost_range_silence_warning( const T& ) { } - + ///////////////////////////////////////////////////////////////////// // end() help ///////////////////////////////////////////////////////////////////// @@ -36,7 +36,7 @@ namespace boost { return s + strlen( s ); } - + #ifndef BOOST_NO_CWCHAR inline const wchar_t* str_end( const wchar_t* s, const wchar_t* ) { @@ -51,7 +51,7 @@ namespace boost ; return s; } -#endif +#endif template< class Char> inline Char* str_end( Char* s ) @@ -64,7 +64,7 @@ namespace boost { return boost_range_array + sz; } - + template< class T, std::size_t sz> inline const T* array_end( const T BOOST_RANGE_ARRAY_REF()[sz] ) { @@ -74,7 +74,7 @@ namespace boost ///////////////////////////////////////////////////////////////////// // size() help ///////////////////////////////////////////////////////////////////// - + template< class Char> inline std::size_t str_size( const Char* const& s ) { @@ -96,7 +96,7 @@ namespace boost } } // namespace 'range_detail' - + } // namespace 'boost' diff --git a/include/boost/range/iterator.hpp b/include/boost/range/iterator.hpp index 4ba9122..2966bdf 100644 --- a/include/boost/range/iterator.hpp +++ b/include/boost/range/iterator.hpp @@ -25,46 +25,46 @@ namespace boost { -#if BOOST_WORKAROUND(BOOST_MSVC, == 1310) - - namespace range_detail_vc7_1 - { - template< typename C, typename Sig = void(C)> - struct range_iterator - { - typedef BOOST_RANGE_DEDUCED_TYPENAME - mpl::eval_if_c< is_const<C>::value, - range_const_iterator< typename remove_const<C>::type>, - range_mutable_iterator<C>>::type type; - }; +#if BOOST_WORKAROUND(BOOST_MSVC, == 1310) - template< typename C, typename T> - struct range_iterator< C, void(T[])> - { - typedef T* type; - }; - } - -#endif + namespace range_detail_vc7_1 + { + template< typename C, typename Sig = void(C)> + struct range_iterator + { + typedef BOOST_RANGE_DEDUCED_TYPENAME + mpl::eval_if_c< is_const<C>::value, + range_const_iterator< typename remove_const<C>::type>, + range_mutable_iterator<C>>::type type; + }; + + template< typename C, typename T> + struct range_iterator< C, void(T[])> + { + typedef T* type; + }; + } + +#endif template< typename C> struct range_iterator { #if BOOST_WORKAROUND(BOOST_MSVC, == 1310) + + typedef BOOST_RANGE_DEDUCED_TYPENAME + range_detail_vc7_1::range_iterator<C>::type type; + +#else - typedef BOOST_RANGE_DEDUCED_TYPENAME - range_detail_vc7_1::range_iterator<C>::type type; - -#else - - typedef BOOST_RANGE_DEDUCED_TYPENAME - mpl::eval_if_c< is_const<C>::value, + typedef BOOST_RANGE_DEDUCED_TYPENAME + mpl::eval_if_c< is_const<C>::value, range_const_iterator< typename remove_const<C>::type>, range_mutable_iterator<C>>::type type; - -#endif + +#endif }; - + } // namespace boost #endif

2 1

Re: [boost] [AFIO] Callback API
by Bjorn Reese 03 Jan '14

03 Jan '14

Moving the discussion from boost-users to boost-dev, and thus the full context is quoted. On 12/21/2013 01:53 AM, Niall Douglas wrote: > On 20 Dec 2013 at 19:16, Bjorn Reese wrote: > >>> Can you suggest something? I honestly can't think of anything simpler >>> which also provides strong write ordering guarantees. >> >> I have not given this much thought so consider the following a >> brainstorm. > > We really ought to move this off boost-users ... but we'll see how it > goes. > >> I am thinking about an API that uses handles that looks more like Asio >> sockets. Write ordering can be handled, not by batching operations >> together, but rather calling the next write operation from the callback >> of the previous operation (Asio-style.) This will not always yield good >> performance, but oftentimes that is less relevant. If you need >> performance, then the "advanced" dispatcher API is available. >> >> So there could be a file handle (and directory handle) class for file >> (directory) manipulation calls, which hides all the details of the >> dispatcher etc. >> >> class file_handle >> { >> public: >> void read(buffer, read_callback); >> void write(buffer, write_callback); >> // and so on >> }; >> >> class directory_handle >> { >> public: >> void create(name, create_callback); // uses file(single) or dir(single) >> void remove(name, remove_callback); // uses rmdir(single) >> void watch(name, watch_callback); // directory monitoring >> // and so on >> }; > > I'm struggling to see the merit in such an approach - it would be > incredibly verbose and complex to write even simple solutions, > because i/o on files is not like sockets, *especially* that you > almost never must strongly order i/o across a sequence of multiple > sockets, but that is a very common case with files e.g. during ACID. First, it follows a pattern that is familiar to Asio users. So rather than you being the only one who can write applications on top of Afio, you get a broader community who are already familiar with the callback approach. Second, you can more easily combine it with Asio socket code to create compound services that mixes socket and file access. For instance, a peer-to-peer file distribution mechanism. > AFIO tries to help users to not write callbacks except when > necessary, but if you do want a user defined callback you simply > chain a call() or completion() operation to the item whose completion > you want called back upon. > > The idea is, you see, that you subclass the async_io_dispatcher class > with additional completion handlers, and use those as building blocks > for further subclasses of async_io_dispatcher. That hopefully gets > people to break up their callbacks into reusable completion handlers, > and saves people writing and debugging code. > Before you say "this should be in the documentation", yes it should > and will be after Paul gets his directory monitoring implementation > working. I'm thinking that will form the fourth section in the > beginner's tutorial - how to modularise and make reusable the > normally bespoke glue code which makes up traditional callbacks. It > might actually be worth adding a section 3b which shows how the naïve > approach in 3a is a very stupid idea :) > > As much as this sort of operation dependency graph based design works > well for its niche, I agree there is a swathe of code which ends up > looking like the find in files implementation, and for that hopefully > fibers will make look much more sane. I am not arguing against the current API. Instead, I am arguing for the addition of a more familiar Asio-style callback API. I have no trouble with a fiber-enchanced API (similar to Asio with coroutines.)

3 5