Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-11-18 02:31:38


I vote to accept the Named parameters library into boost. It
fills a need that is lacking in C++.

> - What is your evaluation of the design?

Very good.

Some comments:

1) WRT DSL, I'm not quite sure about the syntax for
defaults. Example:

     params[name | "unnamed"]

I have a strong feeling that there's a better syntax but I am
not sure what it is now. I read in the thread that the syntax

     params[name] | "unnamed"

is not doable, but I'm not quite sure. Perhaps a clarification
will set me straight. Having the default in the brackets seems to
rather awkward. Perhaps:


is better?

2) Automatic Overload Generation

Is it not possible to elide the use of macros? Instead of:

     template<class Params>
     void foo_impl(const Params&);

         return_type, function_name
       , min_arity, max_arity, keywords_type

I'd very much prefer writing something like:

     struct foo_
         template<class Params>
         struct result { typedef void type; };

         template<class Params>
         void eval(const Params&) const;

     named_interface<foo_, foo_keywords> const foo = foo_();

3) Which brings me to my third point: I notice that
BOOST_NAMED_PARAMS_FUN has a fixed return type. IMO, this is a
big drawback of the macro aproach. The non-macro approach I
presented is fully polymorphic WRT its return type. IOTW, the
return type can be dependent on the arguments (Params).

Oh and, also, I need to be able to generate the overloads through
templates instead of auto generatng the overloads through a

Why is this important? I like the named interfaces a lot and I'd like to
add the facility to Phoenix (BTW, the approach outlined above is
reminiscent of phoenix::function). The two issues I mentioned above
hinders me from using named interfaces.

Fortunately, both appraoches are orthogonal. I can easily add the
named_interface<foo_> overload generators from within Phoenix, so this
is not such a big issue.

> - What is your evaluation of the implementation?

Well written.

> - What is your evaluation of the documentation?

Adequate but there's definitely room for improvement. For example,
there is a section (2.2 Defining the forwarding functions) without
any text at all; just code.

> - What is your evaluation of the potential usefulness of the

I know the usefulness of named params from other languages.
Even the humble HTML language has named parameters. Example:

<img src="hello.gif" alt="Hello">

> - Did you try to use the library? With what compiler?

Yes. VC7.1.

> Did you have any problems?


> - How much effort did you put into your evaluation? A glance? A
> quick reading? In-depth study?

I've been following the development since the beginning.

> - Are you knowledgeable about the problem domain?


Joel de Guzman

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