Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 10:29:44

--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> On Thu, 31 Jan 2002, bill_kempf wrote:
> willia>
> willia> OK, in this particular case I'd be open to that. If
nothing else it
> willia> eliminates the concern for not supporting all operations of
> willia> traits class. However, this isn't the "typical" solution
in C++
> willia> design that I've seen, and as free functions the above
> willia> appear to be more open to misuse. In otherwords,
a "newbie" is
> willia> likely to see:
> willia>
> willia> template <typename Mutex>
> willia> void lock(Mutex& m);
> By free function I didn't mean function template, I was thinking
> functions overloaded on the particular mutex types.

Results in the same thing, though it actually makes the
implementation more difficult. With the current Boost.Threads
implementation the template can be written to cover all mutex
variants, and user defined mutex types (that shouldn't know about the
implementation details) can specialize the template for their types.

> willia> and use it then he is if it's wrapped in a traits class.
If that's
> willia> the case, why not just expose these methods as public
methods in the
> willia> Mutex?
> Good question, why not? Perhaps you should post your design goals
for this
> component. I can guess at them... but I might be wrong and so might
> others.

Making lock() operations easily accessible is likely to lead to
newbie mistakes. Not exposing them at all makes it
difficult/impossible to extend the library, such as with a lock_ptr<>

A trickier issue is that the variants that take the cv_traits
references are implementation details used to allow the mutexes to
work with boost::condition. The more I think about these the more I
don't know what the solution is. Just exposing the methods won't
help anyone, since what they have to do is platform specific. I'm
not at all sure there's a way to refactor it in order to remove this
fact, and so there may be no purpose in exposing the methods at all,
but that means the library can't be portably extended with custom
mutex types that will work with boost::condition.

Bill Kempf

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