From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-06-29 10:08:08
Michael Glassford wrote:
> I would consider this more an argument for eliminating 1-argument
> constructors entirely (except for scoped_lock, where its meaning is
> completely unambiguous):
It does appear that the design of the Scoped*Lock classes was very
deliberate in having distinctly different constructor semantics. Though
it's curious that all three have a L l(m,b) constructor so that
LockType l(m, true);
will always have blocking semantics, regardless of lock type, and that
LockType l(m, false);
will always create an unlocked lock. This being the case, it would be a
convenient shorthand to add
to all three Scoped*Lock concepts to support the generic case of a
blocking lock. But it's just a shorthand, so it can be relegated to a
wish list item.
>> Refinements of a concept can only add restrictions,
>> they cannot remove them.
> True. But it's not hard to define the concepts in such a way that the
> lock classes can have different constructors:
> Lock concept defines all lock operations except constructors.
> TryLock concept refines Lock by adding try_* methods.
> TimedLock concept refines TryLock by adding timed_* methods.
> ScopedLock refines Lock by adding appropriate constructors.
> ScopedTryLock refines TryLock by adding appropriate constructors.
> ScopedTimedLock refines TimedLock by adding appropriate constructors.
This isn't necessary, because the Lock concept that all three currently
refine from does not define any constructors.
Lock concept defines basic lock operations and destructor.
ScopedLock refines Lock by adding constructors.
ScopedTryLock refines Lock by adding constructors and the try_lock method().
ScopedTimedLock refines Lock by adding constructors and the timed_lock
But it looks as if the original concepts are not as generic as I may
have hoped, at least on construction. Perhaps this is the right answer,
as locks are (according to the docs) supposed to be shorted lived objects.
-- Christopher Currie <codemonkey_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk