alnsn@yandex.ru wrote:
Peter Dimov wrote:
- you can return a lock from a function: we can make the locks movable regardless of the interface, so it seems possible to ignore this bullet;
- if( lock l = try_lock( m ) ) { }
This is the main difference.
Declarations in conditions are a nice idiom. The typical use is
if( X x = f() ) { // do something with x }
Our example doesn't fit the pattern, however, as the "// do something" part typically does not reference the lock itself.
This is a degenerate case of more general idea of passing lock reference to functions inside condition:
if(lock_ref l = scoped_lock(m)) { // do something with l: action1(l); action2(l); }
Apparently, action1 and action2 can't be called without prior obtaining of a lock. Plus, you get some sort of polymorphism because the functions can accept other locks as well:
action1(scoped_try_lock(m1)); // lock_ref is const reference action2(scoped_timed_lock(m2));
Oh yeah, I heard a talk by Andrei Alexandrescu in which he endorsed that idiom. (Google for "Honey I shrunk the threads".) I like it, but I've never used it. :-P Actually, in the design I was suggesting, there is only one lock type, so you don't have to mess with multiple types, temporaries bound to const references, or a common base class. This idiom becomes easier to use, IMO, with only one lock type. -- Eric Niebler Boost Consulting www.boost-consulting.com