|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-08 07:15:01
Howard Hinnant wrote:
> On Jul 7, 2004, at 1:45 PM, Peter Dimov wrote:
>
>> My proposal (I'm not sure whether I should be credited for it; Howard
>> posted
>> locks that had these properties and I merely commented) can be made
>> to break
>> such code at compile time, simply by removing the nested
>> TryMutex::scoped_try_lock typedef (as there is no longer a need for
>> it, because ::scoped_lock is a TryLock or TimedLock, as appropriate).
>
> Interesting... I hadn't thought about doing that. But I think I see
> where you're headed. A lock is just a lock, those parts of it you
> need, you instantiate and use. Those parts you don't, you ignore and
> they don't hurt anything (unless you try to explicitly instantiate
> your lock). If you try to use something the templated mutex doesn't
> support, you get a compile time error. Giving that some more
> thought...
Yes, it's even possible to collapse all locks into one templated class. My
point was weaker than that. I wanted to collapse all three locks exposed by
a TimedMutex into one, since with the linear concept hierarchy, there is no
longer any reason to expose separate locks. A single TimedLock - called
TimedMutex::scoped_lock - will suffice. Generic code that only needs a Mutex
or TryMutex can still operate on a TimedMutex.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk