Doug Gregor <dgregor@cs.indiana.edu> 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