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 { public: 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 -- Christopher Currie <codemonkey@gmail.com>