[boost] Re: [Review] Named parameters questions, comments, and food for thought

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-23 14:44:21

Doug Gregor <dgregor_at_[hidden]> writes:

> I've just implemented a new BGL algorithm using the named parameters
> library for the interface. The algorithm itself is very simple, but
> illustrates some of the benefits and pitfalls of the named parameters
> library.
> After writing this, I of course have some questions and comments about
> the named parameters library.
>
> This is not actually a review: that will come later. And don't confuse
> this with my role as review manager.
>
> --------------------------Fixed positional
>                           parameters-----------------------------
> The first issue I ran into was that I really wanted a fixed number of
> positional parameters before any of the named parameters. 

Dealt with in a prior response.

> it's rather hard to deal with creating defaults for named parameters
> that rely on other named parameters. This was never easy (the BGL
> has the same problem), but picking (2) above makes things much
> harder: for instance, the first positional parameter is _always_ the
> graph, and nearly every default value depends on knowing the graph
> type. However, I wouldn't be able to get at the type of p[graph_t()]
> without passing it to another helper function and doing the work
> there.

Well, we also need a static way to get the type of a named parameter:

  named_param<Params, graph>::type

or something.

> ------------------------Default parameters----------------------
> Both normal and lazy defaults work very cleanly. The dispatch to my
> implementation function is quite readable:
>
>      detail::page_rank_impl
>        (g,
>         rank_map,
>         p[done | n_iterations(20)],
>         p[num_active_vertices | num_vertices(g)],
>         p[rank_map2
> 	 || vector_property_map_builder<Graph, rank_type>(g)]);
>
> vector_property_map_builder is a new function object a had to create
> to perform the lazy construction of a vector_property_map, but that
> doesn't hurt so badly. A better version of it would just end up
> somewhere in the BGL and be reused.

Great to hear!

> -----------------------The type of params[foo | def]-------------------

Also dealt with in a prior response.

> ----------------------- Question on boost::keyword -------------------
> If the BGL is going to switch to this library, we are going to need
> backward compatibility. I can do that easily if I'm allowed to derive
> my keywords from boost::keyword instead of using exactly a
> "boost::keyword". Can I do that?

Ditto.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com