Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-14 14:14:44

--- In boost_at_[hidden], jsiek_at_l... wrote:
> William Kempf writes:
> > --- In boost_at_[hidden], jsiek_at_l... wrote:
> > >
> > > Suppose there is a thread library implementation that provides
> > mutex
> > > class but not a condition variable class. Why would you want to
> > > require that their mutex class have a nested typedef for a
> > > non-existent condition variable class?
> >
> > I don't follow this. We're defining the library here. We can
> > that the mutex class must have a CV class. What other libraries
> > defined makes no difference here.
> Actually, at this stage we are *not* defining the library. We are
> defining a set of concepts. Concepts are always completely open-
> They can be implemented in lots of different ways, by lots of
> different concrete types. Boost will have an implementation, but I
> would be disappointed if there were not other implementations as
> well. By carefully designing the concepts, we don't force other
> implementations into a "all or nothing" situation.

I guess I agree with this, though I still have problems resolving it
within context of your argument.

> > Even if you were to argue that we may have a "mutex type" that
> > have a corresponding CV (sounds like a mistake to me, but let's
> > this argument), what's preventing you from simply not including
> > nested CV in this case? I don't see how this is any different
> > the iterator concept having classifications that indicate what
> > functionality is included.
> This suggestion makes more sense, but it is very different from what
> you were saying before.
> What I thought your were proposing before was this:
> concept Mutex
> associated types:
> X::lock
> X::condition_variables
> And what you are now proposing is more like this:
> concept Mutex
> associated types:
> X::lock
> concept MutexWithCV refines Mutex
> associated types:
> X::condition_variable
> This is OK with me, since it doesn't place condition variable inside
> Mutex. However, I think MutexWithCV is a bit unnecessary... why not
> express the coupling in the ConditionVariable class. We currently
> do not have a very precise way of describing this kind of coupling,
> but I'm sure I could add some prose that gets the idea across.

This supposes that there's ever a reason to have a Mutex instead of a
MutexWithCV. I'm not sure that the plain Mutex concept is ever
really valid. I realize that this is a shakey argument on my part,
so maybe I should abandon it. I guess I just don't feel good doing
that just yet. The nesting appeals to me, and I guess it will
continue to until you can point out why it's appropriate for lock but
not for condition. Or, put in another way, why would we ever have a
concrete mutex type with out an associated concrete condition type?

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