Michael Glassford wrote:
Eric Niebler wrote:
I continue to believe that a better interface for a unified lock involves descriptively named helper functions:
I like it better too, but...
scoped_lock l1( m ); // lock unconditionally scoped_lock l1 = defer_lock( m ); // don't lock scoped_lock l2 = try_lock( m ); // try lock scoped_lock l3 = timed_lock( m, t ); // timed lock
It's just as clear as you could hope for, and it's extensible. I feel that the single lock c'tor with a bool arg is less readable and rather inflexible.
Earlier I posted code demonstrating how this interface could be made to work.
I believe there was (nearly?) consensus that we want to make locks movable at some point. My conclusion was that at that point this syntax becomes possible, too. I think Peter said or implied much the same thing, maybe before I did.
As I mentioned in another recent reply, the unified lock won't be in the upcoming release; making locks movable may happen before the next release after that, making this syntax possible in that release also.
This is true, but once we add a scoped_lock constructor that takes a bool, we can't take it back out. If we then added helper functions, we'd be giving people two ways to do the same thing. Not a big deal I suppose, but I'm a minimalist and would prefer only one way.
In your opinion, should a unified lock then have no locking constructors, or should it have only the one already proposed?
My opinion? Hmm ... I'd like to see scoped_lock have one public c'tor that took a mutex and locked unconditionally. That's the most common case, so it should be simple and concise. Everything else would be an appropriately named helper function. My $0.000002. -- Eric Niebler Boost Consulting www.boost-consulting.com