[thread] lock(Iterator,Iterator) bug?

according to this point in the library documentation: http://www.boost.org/doc/libs/1_39_0/doc/html/thread/synchronization.html#th... 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?

Another question. Mutex supposed to be noncopyble. How are going to create vector<mutex> and fill it with mutex instances? On Wed, Aug 19, 2009 at 4:17 PM, <strasser@uni-bremen.de> wrote:
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(), ...

Am Wednesday 19 August 2009 17:34:21 schrieb Ovanes Markarian:
Another question. Mutex supposed to be noncopyble. How are going to create vector<mutex> and fill it with mutex instances?
I don't. this was a test case only. use a container that accepts noncopyables or a copyable Lockable type and you'll get the same results. I didn't even stumble accross this by trying to use lock(), I was looking for a way to check if a type has a certain member. So I was surprised to find code that is supposed to be non-standard c++ in a release version of boost, enabled for almost all compilers. so, is this a bug or am I missing something?
On Wed, Aug 19, 2009 at 4:17 PM, <strasser@uni-bremen.de> wrote:
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(), ...

strasser@uni-bremen.de writes:
according to this point in the library documentation: http://www.boost.org/doc/libs/1_39_0/doc/html/thread/synchronization.html#th...
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(), ...
This is a bug. It worked where I tested it, but my tests were insufficiently extensive. I believe there is a trac entry for this already. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
participants (4)
-
Anthony Williams
-
Ovanes Markarian
-
Stefan Strasser
-
strasser@uni-bremen.de