[Boost-users] [thread] lock(Iterator,Iterator) bug?

Subject: [Boost-users] [thread] lock(Iterator,Iterator) bug?
From: strasser_at_[hidden]
Date: 2009-08-19 10:17:10

according to this point in the library documentation:
http://www.boost.org/doc/libs/1_39_0/doc/html/thread/synchronization.html#thread.synchronization.lock_functions.lock_range

there are, among others, these non-member functions on Boost.Thread:

template<typename ForwardIterator>
void lock(ForwardIterator begin,ForwardIterator end);

template<typename Lockable1,typename Lockable2>
void lock(Lockable1& l1,Lockable2& l2);

this example:

vector<mutex> vec;
lock(vec.begin(),vec.end());

fails on gcc 4.3.2, complaining that the vector iterator doesn`t have  
members named, lock(), unlock(), ...

after looking at the source I`m not even sure how this is supposed to work.
the implementation seems to try to differentiate between Lockable and  
ForwardIterator with this and other templates like it:

template<typename T>
struct has_member_lock{
   typedef char true_type;
   struct false_type{
     true_type dummy[2];
   };

   template<typename U>
   static true_type has_member(U*,void (U::*dummy)()=&U::lock);
   static false_type has_member(void*);

   BOOST_STATIC_CONSTANT(bool,  
value=sizeof(has_member_lock<T>::has_member((T*)NULL))==sizeof(true_type));
};

it looks like it tries to exploit SFINAE but it does so with a default  
argument that is not always resolvable.
an old discussion on the boost mailing list about a has_member type  
trait seems to confirm that there is no portable way to do that and at  
the time only vc++ accepted that kind of code.
but the only requirement placed on including this code is:

#if defined(BOOST_NO_SFINAE) ||                           \
     BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) || \
     BOOST_WORKAROUND(__SUNPRO_CC, BOOST_TESTED_AT(0x590))

am I missing something?