Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2002-01-30 20:13:57


On Wed, 30 Jan 2002, bill_kempf wrote:
> OK, we've discovered the need to move some things I'd considered
> implementation details into some form of public interface. My
> thinking is to define some traits classes that allow these details to
> be specified. The first "draft" of a mutex_traits<> type looks like
> this:
>
> template <typename Mutex>
> class mutex_traits
> {
> public:
> typedef <i>Implementation Defined</i> cv_state;
> static void lock(Mutex& mutex);
> static void trylock(Mutex& mutex);
> static void timedlock(Mutex& mutex);
> static void unlock(Mutex& mutex);
> static void lock(Mutex& mutex, cv_state& state);
> static void unlock(Mutex& mutex, const cv_state& state);
> };

I prefer free functions to static-functions-in-a-traits-class.

> >From a design standpoint, is it OK to use this with types such as
> boost::mutex which don't support all the methods, or do we need
> seperate traits classes for try and timed mutex variants? The
> compiler will catch misuses when using a single traits template, but
> I'm still not sure that it's "proper" to design this with a single
> traits type.

You won't have these problems with a free function approach.

Beware the monolithic interface!

> The other issue is that the above definition won't map to a
> read_write_mutex which doesn't have a lock() operation but instead
> has a read_lock() and a write_lock() operation. I'm not sure how to
> deal with this, or if I actually should deal with it.
>
> Comments/ideas?

If two operations have different semantics, then they should have
different names. If two operations have the same semantics, then we can do
generic programming, and they should have the same name.

My $0.02,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek http://www.osl.iu.edu/~jsiek/
 Ph.D. Student, Indiana Univ. B'ton email: jsiek_at_[hidden]
 C++ Booster (http://www.boost.org) office phone: (812) 855-3608
----------------------------------------------------------------------


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk