From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-01 13:34:55
Batov, Vladimir wrote:
>>Well, as you point out, try_lock is like a timed_lock with
>>time = 0, and lock is like a timed_lock with time = infinity,
>>so why not give timed_lock both lock() and try_lock()
>>methods as shorthand notation for lock(m, t=0) and
> [Batov, Vladimir] Because, in my view, it violates the fundamental (and
> I think widely accepted) OO design principle (guideline?) that in simple
> terms can be expressed as "one class, one responsibility". Names like
> Bertrand Meyer, Herb Sutter and many others immediately come to mind.
> We can either achieve that by having a universal lock (with timed_lock
> as the basis) and shorthand notations in separate derived classes (lock,
> timed_lock and try_lock) or by keeping those three completely unrelated
> (probably at the expense of some code/functionality duplication). I am
> personally leaning towards latter, as even though technically all three
> concepts are related, from the user point of view they are distinct.
>>The argument for try_lock not having a blocking lock() method,
>>which you seem to stress more often, is much clearer; I'm much
>>more inclined to agree with you there.
> [Batov, Vladimir] Thank you. I feel that it is important that every
> class does what it promises to do. No more, no less.
For what it's worth, heres a use case I just ran across illustrating why
timed_lock should have a blocking lock() method and/or a blocking locked
void f(mutex m)
mutex::scoped_timed_lock l(m, locked);
//always want the lock here
//timed_wait requires a timed_lock
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk