Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-03-26 10:06:04

--- In boost_at_y..., Lie-Quan Lee <llee1_at_l...> wrote:

I'm going to go back and respond to the post that originated all of
this later, but this is the perfect opportunity for me to voice out
on this subpoint.

> At Mon, 26 Mar 2001 08:41:54 -0500,
> David Abrahams wrote:
> >
> > In the generative interfaces I have seen, the parameters name
> > Using named template parameters is overkill in this situation.
What we want,
> > for ease-of-use, is simply an interface that allows the
parameters to be
> > passed in any order. That is,
> >
> > mutex_generator<checked, nonrecursive>::type
> >
> > is self-documenting, but should be equivalent to
> >
> > mutex_generator<nonrecursive, checked>::type
> >
> > -Dave
> >
> As a matter of fact, there are quite a few features in the mutexes.
> name a few, blocking policy, checked/unchecked,
> recursive/nonrecursive, acquisition
> scheduling(FIFO/priority/undefined), and owner priority and so
> on.

This illustrates one of the big reasons why I'm not sure I care for a
generative design for Boost.Threads. Acquisition scheduling is
nearly always going to be defined by the underlying implementation,
so exposing an interface to specify this is misleading at best.
You're not going to be able to specify this in a portable manner. I
designed the semantics of the Boost.Threads mutex types very
carefully, taking factors like this into account.

The other reason I'm not sure that I care for a generative approach
is because it leads to a much more complex design both to implement
and to use. If there's a mutex type that you feel is missing I'd
prefer to see it implemented stand alone. If it's a type that can be
easily implemented portably, then it can even be included in
Boost.Threads proper.
> Quickly, the number of template arguements could get larger than
> convenient to remember. Benefits of using named template arguement,
> including having default for all template arguements and making
> of template arguement insignificant, will make users' life easy as
> just suggest to do that in Boost.Graph. What do you think?

I think that the generative approach is going to do anything but make
the user's life easy, regardless of whether or not named template
parameters are used. The "number of template arguments" getting
overly large is just one reason why this is so.

Bill Kempf

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