Boost C++ Libraries: Ticket #2704: range lock algorithm fails with iterators

attachment set

jwakely.boost@… — Sat, 31 Jan 2009 16:15:41 GMT

attachment → boost_locks.patch

patch to use sfinae in is_mutex_type helpers

attachment set

jwakely.boost@… — Sat, 31 Jan 2009 16:23:56 GMT

attachment → boost_locks.2.patch

fixed patch to use sfinae in is_mutex_type helpers

attachment set

jwakely.boost@… — Sat, 31 Jan 2009 16:58:37 GMT

attachment → boost_locks3.patch

take 3! this one's simpler, and doesn't fail if the iterator type happens to have a member like int Iterator::lock(int)

jwakely.boost@… — Sat, 31 Jan 2009 17:11:05 GMT

gah, I've just noticed that trac concatenated the lines in the original test case I posted, so that the problem line was commented out. It should be:

boost::lock(&v.front(), &v.front()+v.size());

boost::lock(v.begin(), v.end());

the second line is the problem.

Ignore the first patch, it's full of copy&paste errors. The second one fixes the original test case above, but fails for an iterator type like:

struct iterator : std::vector<boost::mutex>::iterator {

template<typename T> iterator(T t) : std::vector<boost::mutex>::iterator(t) { }

iterator() : std::vector<boost::mutex>::iterator() { }

iterator& operator++();

iterator operator++(int);

bool lock(int); confuses has_member_lock

};

The lock member means substitution succeeds, but the "dummy" parameter fails to compile because the signature of &U::lock doesn't match.

The third patch handles the case above by extending sfinae_type to only succeed for members with the right signature.

cc set

Fri, 05 Jun 2009 17:00:16 GMT

cc jwakely.boost@… added

viboes — Tue, 08 Jun 2010 11:56:09 GMT

boost::mutex is not copyable, so you can not put them on std::vector. You will need to wait until there is a common move semantics emulation and the associated containers.

Could we close this ticket, or change it as a Feature request?

Tue, 08 Jun 2010 12:09:52 GMT

The bug is not "mutex is not copyable" it is that the range lock algo doesn't work with iterators. The original testcase does not require mutex to be copyable, because it doesn't insert any mutexes into the vector. But it still fails to compile, because of a bug in boost::lock.

If it helps you understand the problem I'll try to come up with a different test case that uses a type that is Lockable and Copyable, instead of boost::mutex

status changed; resolution set

Anthony Williams — Tue, 08 Jun 2010 12:10:46 GMT

status new → closed
resolution → fixed

Fixed on trunk