- Boost - lists.preview.boost.org

[gil] What is the status of the Gil extension numeric?
by Krzysztof Czainski 21 Feb '13

21 Feb '13

Hello, During my first steps wit Boost.Gil I bumped onto an example [1], that uses the numeric extension. For this extension, the the example [1] and a ling from Boost.Gil docs [4] point to [2], where I couldn't find any Gil extensions to download. Most Google links pointed to the same page, but I finally found [3]. So my questions are: a) Is there a plan to add the extension numeric to Boost? b) Is [3] the newest version? And could the Boost.Gil docs be updated to point to the right place? c) I corrected a few bugs in boost/gil/extension/numeric/sampler.hpp -- is this list the right place to discuss modifications to the numeric extension? Regards, Kris [1] http://www.boost.org/doc/libs/1_53_0/libs/gil/example/resize.cpp [2] http://opensource.adobe.com/gil [3] http://code.google.com/p/gil-contributions/ [4] http://www.boost.org/doc/libs/1_53_0/libs/gil/doc/index.html

1 0

[tuple] Functionals for tuple element access?
by Jan Hudec 21 Feb '13

21 Feb '13

Hello All, Doing some heavy template work on collections of pairs and tuples I came across the need for functors returning tuple and pair members. So I looked whether Boost has anything like that, but couldn't find any. Now the functors can be written using bind like: bind(_1, &TupleType::get<3>); bind(_1, &PairType::first); except that requires explicitly mentioning the tuple/pair type. Trying to use simply &boost::tuples::get<3, WHAT?!?!?> even failed for me as boost::tuples::get is actually a 3-argument template based on boost::tuples::cons, which looks like implementation detail I better not rely on. Besides bost methods involve pointer-to-{function,member}, which might interfere with inlining. So I think it would be convenient to have functions like this somewhere in boost: template <int N> struct getter { template <typename X> struct result; template <typename F, typename T> struct result<F(T &)> { typedef BOOST_DEDUCED_TYPENAME element<N, T>::type &type; }; template <typename F, typename T> struct result<F(T const &)> { typedef BOOST_DEDUCED_TYPENAME element<N, T>::type const &type; }; template <typename T> BOOST_DEDUCED_TYPENAME element<N, T>::type & operator()(T &t) { return get<N>(t); } template <typename T> BOOST_DEDUCED_TYPENAME element<N, T>::type const & operator()(T const &t) { return get<N>(t); } }; I would like to ask: 1. Would there be interest in adding this? Should I polish it up? 2. What would be good name and place for it (boost::tuples::getter)? 3. To support pairs, would it be preferred to specialize the N=0 and N=1 cases (unfortunately I don't see how to handle the result struct without copy-paste) or define separate first_getter and second_getter or something like that? 4. The definition of result with const and non-const reference was enough for my uses in boost::transform_value_property_map, but I suspect it does not cover all necessary cases (I need non-reference and rvalue reference for C++11 too, right?) My actual use-case was with boost::transform_value_property_map. I needed several property maps with the same set of keys, so I created one boost::associative_property_map with tuple values and splitted it to maps for the items using the above functor. Obviously nothing of this is needed with C++11 lambdas, but I am stuck having to support some obscure platforms like WinCE 4.2 and for it with MSVC++9.0. -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

[range] [general] making member functions SFINAE-friendly
by Nathan Ridge 21 Feb '13

21 Feb '13

Hi, I recently came across a request to make iterator_range<I>::size() SFINAE-friendly [1]. The respect in which it is not currently SFINAE-friendly is that it is only applicable to instantiations where I is a random-access iterator, but it is defined for all instantiations, and fails with a static assertion if I is not random-access. This makes it impossible to use SFINAE techniques to detect whether "r.size()" is valid where r is some iterator_range. The suggested workaround is to give iterator_range a base class, specialize this base class for random-access iterators, and only define size() in this specialization. I think this deficiency and workaround can be generalized to any template class 'C<T>' with a member function 'foo' that is only applicable for a subset of valid template arguments for 'T'. I am curious what the Boost community thinks about applying this workaround (factoring out the member function into a base class) as a general rule in such situations? Is making the member function SFINAE-friendly worth the decrease in readability? Are there other disadvantages to this workaround? Are there alternative ways of making such a function SFINAE- friendly that don't require introducing a base class? Finally, if the consensus is that such a workaround is not justified in general, is there any reason it should be justified specifically for iterator_range<I>::size()? Regards, Nate [1] https://svn.boost.org/trac/boost/ticket/8011

15 49

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

20 Feb '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

[git] Should I commit to SVN or Git?
by Joaquín Mª López Muñoz 20 Feb '13

20 Feb '13

Hi, I'd like to commit some changes to one of my libs for delivery with Boost 1.54. Should I use SVN as always or begin now using Git for the commit? I've skimmed thru the Git transition project wiki and it doesn't seem to have anything on dates for SVN deprecation etc. 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

5 5

[thread] Is there interest in shared_lock_prioritized?
by Antony Polukhin 20 Feb '13

20 Feb '13

Hi, I've got a very basic implementation and tests of shared_lock_prioritized, that can be used like that: // Events are written down in order of // their execution in different threads shared_lock_prioritized<2 /*priorities count*/ > lock; // thread #1 // Lock with minimal priority lock_shared(); // thread #2 // Lock with minimal priority lock_shared(0); // thread #3 // Lock for writing with priority // greater than locks of threads 1 and 2 // Waits till already acquired locks in #1 and #2 finish // and then writes lock(1); // thread #4 // Will wait till thread #3 finishes, only then acquire lock lock_shared(0); Such shared lock gives us ability to manage order/priority of different lock attempts, we can make write locks have bigger priority that read locks, have multiple priorities writes (ordered write locks) and so on... Is there an interest in it? -- Best regards, Antony Polukhin

2 2

[PropertyMap] proposing compose_property_map
by Guillaume Pinot 19 Feb '13

19 Feb '13

Hi. Using boost graph, and particulary reverse_graph, I needed a compose_property_map adaptor. As it may be interesting to everyone, I propose my code. http://texitoi.eu/~texitoi/compose_property_map/ I had problems to find a good return type for the get() free function. The solution proposed here has the drawback of needing a copy constructible type for the value_type of the FPMap in the concept checks. I didn't find any other type for the get() function that pass the concept checks and that do not return stack variable, and avoid useless copy. The patch may not work completely as I am discovering the boost build system. I am open to any comment. Thanks.

2 4

[interprocess] atomic<offset_ptr>
by Tim Blechmann 19 Feb '13

19 Feb '13

hi ion, i was wondering, what would be the best way to provide an atomic<offset_ptr>? it cannot be used out of the box, as offset_ptr does not conform to the std/boost::atomic<> requirements. afaict, one would have to pre-compute the offset for a specific memory location when performing a compare_exchange or store and fix up the offset after an atomic load. to do that, it will probably be required to access some internals of the offset_ptr. also, if i'm going to work on it (not sure if i will have time), where shall the implementation go? in a way, i'd rather put it into interprocess than into atomic. thoughts? cheers, tim

2 2

[test] recent commit causing general failure
by Joaquín Mª López Muñoz 19 Feb '13

19 Feb '13

Boost.MultiIndex trunk tests fail all over with message errors like this: C:\...\boost/test/impl/test_main.ipp(39) : error C3861: 'BOOST_CHECK': identifier not found which is seemingly caused by the suppresion of an internal #include in a recent change to Boost.Test: https://svn.boost.org/trac/boost/changeset/82718#file5 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

4 6

Tests failing?
by Marshall Clow 19 Feb '13

19 Feb '13

A bunch of my (String.Algo and Boost.Algo) tests are failing locally, with errors like: darwin.compile.c++ ../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o In file included from ../../../libs/test/src/test_main.cpp:16: ../../../boost/test/impl/test_main.ipp: In member function 'void test_main_caller::operator()()': ../../../boost/test/impl/test_main.ipp:39: error: 'BOOST_CHECK' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -gdwarf-2 -fexceptions -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o" "../../../libs/test/src/test_main.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o... Before I dive into this - is anyone else seeing this? Looking at the test results on the web site, it appears that Boost.Test is broken for several libraries. For example: http://www.boost.org/development/tests/trunk/developer/algorithm.html http://www.boost.org/development/tests/trunk/developer/crc.html http://www.boost.org/development/tests/trunk/developer/geometry.html -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

7 16