Howard Hinnant wrote:
On Jul 15, 2004, at 2:58 PM, Michael Glassford wrote:
My original intent was to add constructors that would make it explicit whether you were asking for a blocking lock, a try lock, or a timed lock, and to remove the ambiguity in the try_lock constructors (rather arbitrarily, one is blocking, the other non-blocking, even though they look just like the lock class constructors which both block). There were some who argued against my idea and none who supported it, so I dropped the it.
Fwiw, I'm still toying with:
lock(m, not_locked); lock(m, not_blocked);
(or whatever the spelling was). I haven't been using that syntax in my examples simply because I don't have it coded that way and I try to compile my example code before I post it (at least usually). Anyway, I'm personally not ready to drop the enum set you proposed, or at least a subset of it.
OK, thanks for the feedback. For what it's worth, then, the latest form of the proposal (which I'm not sure I ever posted) looked like this: namespace lock_state { typedef enum { unlocked=0, locked=1 } lock_state; } //namespace lock_state namespace blocking_mode { typedef enum { non_blocking=0, blocking=1 } blocking_mode; } //namespace blocking_mode ScopedLock / ScopedReadLock / ScopedWriteLock --------------------------------------------- lock(M) //always locking, blocking lock(M, lock_state) //blocking ScopedTryLock / ScopedTryReadLock / ScopedTryWriteLock ------------------------------------------------------ try_lock(M) //always locking, BLOCKING try_lock(M, lock_state) //BLOCKING try_lock(M, blocking_mode) //always locking ScopedTimedLock / ScopedTimedReadLock / ScopedTimedWriteLock ------------------------------------------------------------ timed_lock(M) //always locking, blocking timed_lock(M, lock_state) //blocking timed_lock(M, blocking_mode) //always locking timed_lock(M, t) //always locking, blocking for time t
There's a lot of stuff that's been proposed. Perhaps we need competing implementations that can be played with (as opposed to just competing designs).
Mike