Boost logo

Boost :

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-17 18:20:07

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
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
The first issue I ran into was that I really wanted a fixed number of
positional parameters before any of the named parameters. These
parameters will not have defaults and there is no reason to allow them
to have names. I say this is an "issue" and not a "problem" because
there are several workarounds:
        1) Don't use BOOST_NAMED_PARAMS_FUN; write out the forwarding
functions manually. (This is the option I chose)
        2) Make the required, positional parameters into named parameters (so
that we can use BOOST_NAMED_PARAMS_FUN) but do not provide the objects
of type "keyword" for these parameters. So, for instance, I'll have
"struct graph_t {};" but no corresponding keyword
"boost::keyword<graph_t> graph;". The algorithm would also have to use
boost::named_param to say that there is no default value for these

I chose option (1) for various reasons. The primary reason actually had
to do with something another reviewer brought up: 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.

------------------------Default parameters----------------------
Both normal and lazy defaults work very cleanly. The dispatch to my
implementation function is quite readable:

        p[done | n_iterations(20)],
        p[num_active_vertices | num_vertices(g)],
         || 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.

-----------------------The type of params[foo | def]-------------------
Going into this, I had the notion that I'd be able to use
BOOST_NAMED_PARAMS_FUN to eliminate all of the extra levels of
dispatching calls. It still took 3 levels of function calls: 1 for
bundle the parameters, one to stick defaults in, and one to do the
actual work. If we could get the return type of p[foo | def] or p[foo
|| def] directly, we could solve those problems. To make that usable,
perhaps some"auto"-like macro:

        BOOST_NAMED_PARAMS_AUTO(g, graph_t);
        BOOST_NAMED_PARAMS_AUTO_DEF(done, done_t, n_iterations(20));
        BOOST_NAMED_PARAMS_AUTO_LAZY_DEF(rank_map2, rank_map2_t,

        Unfortunately, I think we need typeof to do that :)

----------------------- 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?

More comments and probably a real review later... I want to go home now.


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