Michael Glassford <glassfordm@hotmail.com> writes:
The point being that TryLock is a refinement of Lock, and TimedLock is a refinement of TryLock? If so, I agree that's better than TryLock and TimedLock both refining Lock. There are still the constructor issues to deal with in such a lock taxonomy, however. The main one: how do you define destructors that are consistent within a lock concept and also consistent between concepts. E.g., on the one hand it seems that a one-parameter constructor should do the same thing in all lock types--so it would have to block; on the other hand, it seems that TryLock constructors should not block unless instructed to do otherwise.
One possible answer is that construction protocol simply isn't part of the concept taxonomy. Another possible answer might lie in considering syntax alternatives for lock construction. For example, a named parameter interface: Lock l(block = m); TryLock l(block = m); TryLock l(proceed = m); TimedLock l(wait = m, t); That particular expression of the idea is probably too cute, but I'm just trying to expand the boundaries of thought. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com