Boost logo

Boost :

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-06-29 07:44:54

Michael Glassford wrote:

> Christopher Currie wrote:
>> TryLock: What would be the semantics of l(m, NO_LOCK, b)? In other
>> words, if you're not going to lock on construction, why specify a
>> blocking policy?
> The only reason is so that if you write l(m, LOCK, ...) you could also
> specify the blocking parameter. An expansion of Vladimir Batov's of
> using structs rather than enums could help here:
> struct nolock_t {};
> nolock_t nolock;
> struct lock_t {};
> lock_t lock;
> class TryLock
> {
> TryLock(TryMutex m, no_lock_t s)
> {...}
> TryLock(TryMutex m, lock_t s, blocking_t b)
> {...}
> }

An interesting syntax, I can see how it does make explicit whether you
are locking or not. Personally, I dislike having to type an extra
argument when it's the only choice; IMO if you're specifying a blocking
parameter, the locking is implied, and therefore superfluous. I was
thinking something like (going back to enums for a moment):

enum { unlocked = 0, locked } lock_init;
enum { nonblocking = 0, blocking } blocking_action;

class TryLock
   TryLock( TryMutex m, lock_init s = locked ) { ... }

   TryLock( TryMutex m, blocking_action b ) { ... }

Also, going back to the struct technique, do the struct instances need
to be in an anonymous namespace to prevent ODR violations? Just trying
to get my head around the concept.


Christopher Currie <codemonkey_at_[hidden]>

Boost list run by bdawes at, gregod at, cpdaniel at, john at