Boost logo

Boost :

From: jsiek_at_[hidden]
Date: 2000-08-14 13:15:11

William Kempf writes:
> --- In boost_at_[hidden], jsiek_at_l... wrote:
> >
> > Suppose there is a thread library implementation that provides a
> 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 decide
> that the mutex class must have a CV class. What other libraries have
> defined makes no difference here.

Actually, at this stage we are *not* defining the library. We are just
defining a set of concepts. Concepts are always completely open-ended.
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.

> Even if you were to argue that we may have a "mutex type" that won't
> have a corresponding CV (sounds like a mistake to me, but let's use
> this argument), what's preventing you from simply not including the
> nested CV in this case? I don't see how this is any different from
> 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:

And what you are now proposing is more like this:

concept Mutex
  associated types:

concept MutexWithCV refines Mutex
  associated types:

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.



 Jeremy Siek www:
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame cell phone: (415) 377-5814

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