February 2013 - Boost - lists.boost.org

[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

[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

Re: [boost] (no subject)
by Vishnu M Menon 19 Feb '13

19 Feb '13

http://www.morguardlogistics.com/ssgd/uc9d53wpgmm.9z7a?nvb0jr11asciq Vishnu M Menon 2/19/2013 6:03:25 PM

1 0

[algorithm] gather.hpp include guard
by Ian Hobson 19 Feb '13

19 Feb '13

Hi, The include guard in boost/algorithm/gather.hpp on SVN is incorrect: #ifndef BOOST_ALGORITHM_GATHER_HPP #define ADOBE_ALGORITHM_GATHER_HPP Best, Ian

2 1

Release Managers: permission to merge small feature to release?
by Marshall Clow 19 Feb '13

19 Feb '13

I have a ticket <https://svn.boost.org/trac/boost/ticket/7652> asking for compile-time checked access to elements of a boost::array. I have implemented a specialization of boost::get (and for c++11, std::get) that does this, and it's been on the trunk and being tested for a couple weeks. This is technically not a bug fix, but new functionality, but I'd like to get it into the next release. So, I'm asking permission to merge to release. The change lists are 82083 (for the functionality), 82084 and 82102 (for the tests), and 82103 (for the docs) Thanks! -- Marshall

5 5