From: David Abrahams (dave_at_[hidden])
Date: 2007-07-10 20:54:36
on Tue Jul 10 2007, Andrew Sutton <asutton-AT-cs.kent.edu> wrote:
> I've been working on parts of the Boost.Graph library as part of my
> Google Summer of Code project. Part of this has been implementing
> some new algorithms. Jeremy Siek (mentor) and I had briefly discussed
> using the new Boost.Parameter library instead of the older BGL Named
> Params solution for building the interfaces to these new algorithms.
> In fact, we had also talked about the possibility of migrating
> existing algorithms to use that style. So... after some initial
> experimentation, I've come up with some questions.
> I've just finished reading most of the original reviews for
> Boost.Parameter library. They weren't that helpful.
Hmm, too bad.
> 1. It seems to me that functions with named parameters are limited to
> 5 parameters (both required and optional) - at least under GCC 4.1.2.
> Is this right?
That's just a default. Please see
> 2. I've run into the situation where parameters are truly optional -
> they don't specify default values, but optional components to an
> algorithm. What's the best way to implement this? How can I test
> (within a function) to determine if a parameter has been passed or
> not? I've hacked together an approach using a `not_given` struct. Is
> there something already like this in the library.
Sure; you could use boost::parameter::void_ as shown here:
> 3. And the big kind of fuzzy question: Is there any general
> documented advice on building procedural interfaces with numerous
> default and replaceable arguments? These are all related to interface
> design and, if anybody responds, might generate some interesting
> discussion. Specific questions:
> - At what point should an interface consider migrating to a named
> parameter solution instead of providing overloads?. For example, I
> could probably write many of my algorithms using overloads, but in
> order to be consistent with Boost.Graph (and other reasons) I'd like
> to use Boost.Parameter.
Well, don't forget the "deduced parameter" solution; that's even
better than overloads.
I guess I would think first about which interface will be more
expressive for your users, and second about which is more expressive
for you as a library builder. If the solution with overloads results
in writing lots of code, especially if there's lots of repetetive
boilerplate, that's another good sign you should be doing it
> - Which is better: executing behavior based on type or value
> parameters and when would each be appropriate? For example, should I
> pass a bool or enum flag to the function and make decisions at
> runtime, or should I define some policy- or tag-style structs and use
> template instantiation to determine behavior at compile time?
They serve different purposes. Do your users know which behavior they
want at compile time?
Also, note that one can always add a runtime choice wrapper on top of
an interface that provides a compile time choice, but you can't go the
> - What's the best way to document these interfaces. Aside from
> Boost.Graph, I haven't yet seen any libraries, but those are
> documented for BGL named params. How do you describe the signature of
> a function that's declared as a macro?
I would proably invent a hypothetical C++ declaration syntax (as
though named/deduced paramters were built-in features), document that,
and then document the functions in terms of it.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk