id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
2704	range lock algorithm fails with iterators	jwakely.boost@…	Anthony Williams	"#include <boost/thread.hpp>

#include <vector>

int main()
{
    std::vector<boost::mutex> v;

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

    return 0;
}

With GCC 4.3.2 and 4.4 this fails to compile, complaining that std::vector<mutex>::iterator does not have members lock, unlock and try_lock e.g.
/home/redi/src/boost/boost/thread/locks.hpp: In static member function ‘static char boost::detail::has_member_try_lock<T>::has_member(U*, bool (U::*)()) [with U = __gnu_cxx::__normal_iterator<boost::mutex*, std::vector<boost::mutex, std::allocator<boost::mutex> > >, T = __gnu_cxx::__normal_iterator<boost::mutex*, std::vector<boost::mutex, std::allocator<boost::mutex> > >]’:                                                                                            
/home/redi/src/boost/boost/thread/locks.hpp:75:   instantiated from ‘const bool boost::detail::has_member_try_lock<__gnu_cxx::__normal_iterator<boost::mutex*, std::vector<boost::mutex, std::allocator<boost::mutex> > > >::value’                                                                                     
/home/redi/src/boost/boost/thread/locks.hpp:84:   instantiated from ‘const bool boost::is_mutex_type<__gnu_cxx::__normal_iterator<boost::mutex*, std::vector<boost::mutex, std::allocator<boost::mutex> > > >::value’                                                                                                   
/home/redi/src/boost/boost/thread/locks.hpp:1133:   instantiated from ‘void boost::lock(const MutexType1&, const MutexType2&) [with MutexType1 = __gnu_cxx::__normal_iterator<boost::mutex*, std::vector<boost::mutex, std::allocator<boost::mutex> > >, MutexType2 = __gnu_cxx::__normal_iterator<boost::mutex*, std::vector<boost::mutex, std::allocator<boost::mutex> > >]’                                                                                                      
lock_range.cc:10:   instantiated from here

The commented-out line above compiles fine, using mutex* as the Iterator type rather than std::vector<mutex>::iterator.

I don't think SFINAE applies in has_member_try_lock<T>::has_member<U>, because bool(U::*)() is a valid type for iterators classes, so substitution succeeds, but &U::try_lock is not a valid expression.

In the pointer case where U is a pointer, bool(U::*)() is not a valid type, so substitution fails, but is not an error.

The attached patch (against trunk) adds another default argument to has_member_{lock,try_lock,unlock}::has_member with a type that depends on the presence of a member with the right name.  I think this would still fail to compile if used with an iterator type that had a member lock/try_lock/unlock with a different signature to that expected by the Lockable concept.

Jonathan
"	Bugs	closed	Boost 1.38.0	thread	Boost 1.37.0	Problem	fixed		jwakely.boost@…