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

[log] MSVC 9 build hangs
by Andrey Semashev 04 Oct '13

04 Oct '13

Hi, Many test results for Boost.Log on teeks99-03b-win2008-64on64 [1] show that the build aborts due to timeout. From the test setup description (2 GiB of RAM, 2 CPUs, 4 build jobs) it seems that the problem could be in the insufficient system resources. 4 jobs building Boost.Log can easily exceed 2 gigs of RAM, especially considering some of the memory is reserved by OS and other programs. If there isn't any swap, the build may be just aborting, and if there is, it's probably performing dead slow. And 2 cores might also be too limiting. Could the tester take a look what is happening on that setup? If it's not a resource problem, then I would appreciate any information on the problem. [1] http://www.boost.org/development/tests/trunk/developer/log.html

3 27

[accumulators] Help understanding implementation of weighted accumulators
by Gabriel Redner 02 Oct '13

02 Oct '13

Hi folks, I am trying to implement a weighted accumulator, but I'm having trouble understanding a few things about the existing ones. Looking at the implementation of weighted_sum, I see (weighted_sum.hpp:37): template<typename Args> weighted_sum_impl(Args const &args) : weighted_sum_( args[parameter::keyword<Tag>::get() | Sample()] * numeric::one<Weight>::value ) { } My questions are: - It's taking the first sample from the args and multiplying it by a weight of 1. Isn't this wrong - ignoring the real weight of this sample? Shouldn't this produce incorrect results? - I've never understood anyways how there can be an initial argument during construction of the accumulator. I haven't found any explanation in the docs beyond "Maybe there is an initial value in the argument pack". Maybe? How? Probably more questions later. Thanks, -Gabe

2 4

[thread] semaphore
by Tim Blechmann 02 Oct '13

02 Oct '13

hi all, i've submitted an implementation of semaphores for boost.thread to trac [1]. they provide an interface similar to boost.interprocess semaphores, with the exception of having chrono-style try_wait_for and try_wait_until members for timed_wait. the patch provides the following implementations: * win32 semaphores (tested with windows 8) * posix semaphores (tested with linux) * dispatch semaphores (tested with osx 10.8) * mutex/condition_variable/counter emulation the native implementations are much faster than the fallback, in microbenchmarks with high contention, i've seen a speedup of 30 to 80. would be great if they can be incorporated into boost.thread. comments/suggestions on the API are highly appreciated. cheers, tim [1] https://svn.boost.org/trac/boost/ticket/8797

10 29

[scope_exit] D-style scope(failure) and scope(success) in C++
by Evgeny Panasyuk 30 Sep '13

30 Sep '13

Hello all, D language has scope(exit), scope(success) and scope(failure) features - http://dlang.org/statement.html#ScopeGuardStatement : "... scope(exit) executes NonEmptyOrScopeBlockStatement when the scope exits normally or when it exits due to exception unwinding. scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. scope(success) executes NonEmptyOrScopeBlockStatement when the scope exits normally. ..." Andrei Alexandrescu describes some of uses cases for scope(exit), scope(success), scope(failure) at his recent talk : http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Suc… There is Boost.ScopeExit library which emulates D's scope(exit) via BOOST_SCOPE_EXIT macro, but there are no analogues for D's scope(failure) and scope(success). Current alternative for these features is ScopeGuard idiom ( http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard , http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/1844037… ). Boost.ScopeExit library itself suggests to use ScopeGuard - http://www.boost.org/doc/libs/1_51_0/libs/scope_exit/doc/html/scope_exit/al… : " Boost.ScopeExit is similar to scope(exit) feature built into the D programming language. A curious reader may notice that the library does not implement scope(success) and scope(failure) of the D language. Unfortunately, these are not possible in C++ because failure or success conditions cannot be determined by calling std::uncaught_exception (see Guru of the Week #47 for details about std::uncaught_exception and if it has any good use at all). However, this is not a big problem because these two D's constructs can be expressed in terms of scope(exit) and a bool commit variable (similarly to some examples presented in the Tutorial section). " I have made small library ( https://github.com/panaseleus/stack_unwinding#d-style-scope-guardsactions ) which supplies primitives (class unwinding_indicator, UNWINDING_AWARE_DESTRUCTOR macro) to determining when object destructor is called due to stack-unwinding or due to normal scope leaving. Currently it is implemented on top of platform-specific implementation of uncaught_exception_count function and tested on: {MSVC2005, MSVC2008, MSVC2010, MSVC2012, GCC4.1.2, GCC4.4.6, Clang3.2}x{x32, x64}x{default settings}. uncaught_exception_count is a function similar to std::uncaught_exception from standard library, but instead of boolean result it returns unsigned int showing current count of uncaught exceptions. Such primitives allow us to implement scope(success) and scope(failure) features in C++. I have made several proof-of-concepts: * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_ac… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/example_… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_gu… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/boost_sc… boost_scopes.cpp example shows usage of BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS: try { cout << "Case #1: stack unwinding" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END throw 1; } catch(int){} { cout << "Case #2: normal exit" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END } Output is: " Case #1: stack unwinding failure exit Case #2: normal exit success exit " Currently BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS are implemented based on boost_1_51_0/boost/scope_exit.hpp by copy-paste and replace (just for proof-or-concept, of course it is possible solution with much less duplication). Semantically meaningful changes can be viewed as diff at https://github.com/panaseleus/stack_unwinding/commit/d5513404323490ea99d9b6… Before posting here, I made posts on several C++ forums, but unfortunately get only a few feedbacks regarding ScopeFailure and ScopeSuccess. What do you think? Thank you. P.S. Related discussion: http://lists.boost.org/Archives/boost/2010/09/171051.php Best Regards, Evgeny Panasyuk

6 27

[thread] synchronized_value: value and move semantics
by Vicente J. Botet Escriba 24 Sep '13

24 Sep '13

Hi, boost::synchronized_value (not released yet [1][2][3]) is based on [4]. See below part of this paper adapted to the Boost.Thread interface. Currently boost::synchronized_value is in addition Copyable and Swappable. I was wondering if it is worth adding value and move semantics to synchronized_value. Making it EqualityComparable, LessThanComparable and Movable if the underlying type satisfy these requirements will allow to store them on a Boost.Container/C++11 container. Do you see something completely wrong with this addition? Has some of you had a need for this? Could you share the context? Best, Vicente [1] https://svn.boost.org/svn/boost/trunk/boost/thread/synchronized_value.hpp [2] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_valu… [3] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_pers… [4] "Enforcing Correct Mutex Usage with Synchronized Values" by Anthony Williams http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/2252002… ------------- [section The Problem with Mutexes] The key problem with protecting shared data with a mutex is that there is no easy way to associate the mutex with the data. It is thus relatively easy to accidentally write code that fails to lock the right mutex - or even locks the wrong mutex - and the compiler will not help you. std::mutex m1; int value1; std::mutex m2; int value2; int readValue1() { boost::lock_guard<boost::mutex> lk(m1); return value1; } int readValue2() { boost::lock_guard<boost::mutex> lk(m1); // oops: wrong mutex return value2; } Moreover, managing the mutex lock also clutters the source code, making it harder to see what is really going on. The use of synchronized_value solves both these problems - the mutex is intimately tied to the value, so you cannot access it without a lock, and yet access semantics are still straightforward. For simple accesses, synchronized_value behaves like a pointer-to-T; for example: boost::synchronized_value<std::string> value3; std::string readValue3() { return *value3; } void setValue3(std::string const& newVal) { *value3=newVal; } void appendToValue3(std::string const& extra) { value3->append(extra); } Both forms of pointer dereference return a proxy object rather than a real reference, to ensure that the lock on the mutex is held across the assignment or method call, but this is transparent to the user. [endsect] [/The Problem with Mutexes] [section Beyond Simple Accesses] The pointer-like semantics work very well for simple accesses such as assignment and calls to member functions. However, sometimes you need to perform an operation that requires multiple accesses under protection of the same lock, and that's what the synchronize() method provides. By calling synchronize() you obtain an strict_lock_ptr object that holds a lock on the mutex protecting the data, and which can be used to access the protected data. The lock is held until the strict_lock_ptr object is destroyed, so you can safely perform multi-part operations. The strict_lock_ptr object also acts as a pointer-to-T, just like synchronized_value does, but this time the lock is already held. For example, the following function adds a trailing slash to a path held in a synchronized_value. The use of the strict_lock_ptr object ensures that the string hasn't changed in between the query and the update. void addTrailingSlashIfMissing(boost::synchronized_value<std::string> & path) { boost::strict_lock_ptr<std::string> u=path.synchronize(); if(u->empty() || (*u->rbegin()!='/')) { *u+='/'; } } [endsect] [/Beyond Simple Accesses] [section Operations Across Multiple Objects] Though synchronized_value works very well for protecting a single object of type T, nothing that we've seen so far solves the problem of operations that require atomic access to multiple objects unless those objects can be combined within a single structure protected by a single mutex. One way to protect access to two synchronized_value objects is to construct a strict_lock_ptr for each object and use those to access the respective protected values; for instance: synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { strict_lock_ptr<std::queue<MessageType> > u1 = q1.synchronize(); strict_lock_ptr<std::queue<MessageType> > u2 = q2.synchronize(); if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } This works well in some scenarios, but not all - if the same two objects are updated together in different sections of code then you need to take care to ensure that the strict_lock_ptr objects are constructed in the same sequence in all cases, otherwise you have the potential for deadlock. This is just the same as when acquiring any two mutexes. In order to be able to use the dead-lock free lock algorithms we need to use instead unique_lock_ptr, which is Lockable. synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { unique_lock_ptr<std::queue<MessageType> > u1 = q1.unique_synchronize(boost::defer_lock); unique_lock_ptr<std::queue<MessageType> > u2 = q2.unique_synchronize(boost::defer_lock); boost::lock(u1,u2); // dead-lock free algorithm if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } [endsect] [/Operations Across Multiple Objects]

1 0

[Operators] empty_base should be untemplated?
by Andrew Ho 21 Sep '13

21 Sep '13

I've noticed about the empty_base class is that it's templated with type T, and I don't think it should be. Fyi, the empty_base class is there to turn multiple inheritance into a single inheritance chain (due to compiler deficiencies/object size bloat on at least Visual Studio). I don't see why this empty_base should be templated, and it would be better suited if it wasn't since all I can think it does is make the compiler work harder. Does anyone know why it was templated to begin with? Additionally, are we safe to change empty_base to be not use templates?

4 4

Boost.Mock ?
by Mathieu Champlon 21 Sep '13

21 Sep '13

Hello, Would a library for mock objects be of interest ? The documentation can be found here : http://mat007.users.sourceforge.net/boost_mock/ An archive is also available for download there : http://sourceforge.net/projects/mat007.u/files/boost-mock.zip It's been converted from turtle (http://turtle.sourceforge.net/) which was mentioned on the mailing-list a couple of times in the past. There is a catch in that it needs Boost.Test from the release branch and doesn't compile with the trunk. The changes are minimal though and I can provide a patch if anyone is interested. Would the library be worth a review ? In the meanwhile I would be highly interested in any feedback ! Thank you, MAT.

4 4

[voronoi]medial axis
by Louis Lavery 19 Sep '13

19 Sep '13

[mods: I posted this a few days ago, and that post was acknowledged etc (it was my first post as a new subscriber) but I haven't receieved a copy myself and cannot find it in the archives - perhaps I should be more patient?] Hello, I'm hoping to use boost voronoi to construct the (internal) medial axis for closed shapes (with holes). I need to work out which vertices of the voronoi are inside, outside and on a boundary. So my first goal is to determine which vertices correspond to the ends of the input segments (boundary vertices). The way I do this at the moment, is to look at each edge and test if its source vertex, vertex0(), is equal to either end point of the segment contained by the edge's cell. (1) If it is then it's a boundary vertex otherwise it's not. Is that correct? (2) When comparing a vertex with an input point can I do an exact compare (==) or should I use a tolerance (epsilon)? Thanks, fuzzy.

2 8

[COUNTERTREE + SUBALLOCATOR ] version 2.0
by Francisco José Tapia 13 Sep '13

13 Sep '13

Hi this message is to announce the version 2.0 of the *[countertree + suballocator]* library. 1 year ago I presented the request for the evaluation of the [countertree+ suballocator] version 1.0. The approval process is stopped due to the absence of review managers, and in the meanwhile I continued with the develop of this version 2.0. Actually the most important libraries and environments for parallel development, *don't provide parallel algorithms for th**e** data structures based on trees* ( set , multiset, map and multimap), and all the operations with these data structures are done with 1 thread. This is due to the difficult to divide the element of the tree between an arbitrary number of threads. (If you want to access to the element in the position 1000, you must go sequentially forward from the position 0 or sequentially backward from the last position. The [countertree + suballocator] library provide data structures set, multiset,map and multimap compatibles with the STL data structures *plus the access to the elements by their position like in a vector, and random access iterators*, You can manage it like a vector. Many parallel algorithms designed for vectors, can be used without changes with the countertree data structures. This make *easy **the **design **of **parallel algorithms* for these data structures. In the library there are a concurrent and a non concurrent versions of all the data structures. The non concurrent version are designed for to be executed inside 1 thread, or for to be accessed by several threads only in read operations (like the STL data structures), they provide a bit more speed than the concurrent version. The concurrent version is *thread safe with all the operations*, one thread can be read and other writing over the same data structure in a safe mode ( as you can see in 2.3 -examples) The concurrent library provide the full set of functions of the STL , plus an *additional set of functions*. These functions have the mission of resolve the problems appeared in the concurrent development. By example, you have a map, find an iterator from a key and with the iterator modify the element, but in the middle, other thread delete the element, and when try to access with the iterator, the program crash, and it is very difficult to reproduce the error for to debug. These additional functions make a pack with the two things, first with a read lock which permit concurrent reads, and when obtain the iterator with an exclusive lock for to modify. These additional functions *prevent the problems* like the previously described, with an *easy interface* for to understand and use for the final user. I don't know if exist any other library with tree based structures with random access iterators. I had search for and didn't find. If someone knows someone, please, say me, I am interested to know something new and collect good ideas. I suppose it don't exist because i didn't see parallel support for data structures based on trees, in any library or parallel tools. I request help to the Boost community because I am in the *moment “perhaps” *. Perhaps I forgot something, perhaps something is wrong, perhaps someone decision was not correct, perhaps it can be done in other way... *Please*, is someone see any fail, any omission, any alternative or simply any comment, please say me, in order to reach the final objective, *provide to the C++ community a good, fast, robust and reliable tool.* In my opinion, this library or other with similar functionality, is the last big part needed for to begin to think about a *concurrent STL* . You can find concurrent libraries with vectors and arrays. You have too, concurrent libraries with containers based on hash functions. With the countertree library you have concurrent set, multiset,map and multimap. The concurrent linked list can be implemented with the concurrent vector_tree ( other data structure of the library). The concurrent STL is a very big project, and must involve many agents and perspectives. From the users associations, to big computers makers and big data providers, passing by the compiler makers, the parallel tools providers... But I am sure the *Boost community* will play a central role by prestige, knowledge and experience designing libraries You can find the documentation and the code in the GitHub https://github.com/fjtapia/countertree_2.0 or you can see online in my dropbox page : https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/index.html<https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/doc/index…> If you prefer download a file with all the code and the documentation : https://github.com/fjtapia/countertree_2.0/blob/master/doc/countertree_2.0.… Sincerely yours Francisco Tapia fjtapia(a)gmail.com ** I you don't try the library, perhaps the most interested parts of the documentation is the 1.5.- Next improvements. Where explain the future parallel algorithms for the library and how they can improve others areas of the computation with the augmented trees.*

3 6

[asio] boost::asio::async_connect reports success on failure
by Ben Pope 13 Sep '13

13 Sep '13

Hi all, I've found a regression between 1.53 to 1.54; if you compile boost/libs/asio/example/cpp11/chat/chat_client.cpp and point it at a host and port that doesn't exist or refuses the connection, instead of coming back with an error, such as host not found or connection refused, it reports success (on the conversion to bool). (you might want to embellish the example with a std::cout << error_code.message() << std::endl;) This appears to be the case across Linux, Darwin, iOS and Android :( synchronous connect seems to work correctly (i.e., echo/blocking_tcp_echo_client.cpp) Ben

2 4