RE: [boost] Comments on the thread library

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-26 09:16:31

> -----Original Message-----
> From: Lie-Quan Lee [mailto:llee1_at_[hidden]]
> Sent: Monday, March 26, 2001 9:03 AM
> To: David Abrahams
> Cc: boost_at_[hidden]
> Subject: Re: [boost] Comments on the thread library
>
>
>
> At Mon, 26 Mar 2001 08:41:54 -0500,
> David Abrahams wrote:
> >
> > In the generative interfaces I have seen, the parameters name
> themselves.
> > 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. To
> name a few, blocking policy, checked/unchecked,
> recursive/nonrecursive, acquisition
> scheduling(FIFO/priority/undefined), and owner priority and so
> on.
>
> 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 order
> of template arguement insignificant, will make users' life easy as you
> just suggest to do that in Boost.Graph. What do you think?
>

I think you miss my point ;-)

Which of the following 2 invocations is clearer?

mutex_generator<checking_policy<checked>::recursion_policy<nonrecursive>::bl
ocking_policy<blocking>::sheduling_policy<priority> >::type

        mutex_generator<checked, nonrecursive, blocking, priority>::type

Asking people to remember the parameter names (e.g. "recursion_policy") in
addition to the possible parameters (e.g. "nonrecursive") is no service to
users. It should be possible to arrange for arbitrary parameter ordering and
sensible defaults without using named template parameters here. I think that
it's actually easier to implement as well.

-Dave