Boost logo

Boost :

From: Andrew Sutton (asutton_at_[hidden])
Date: 2007-07-10 08:37:07


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.

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?

If I try to add a 6th, I get a number of compiler errors of the form
"6 arguments given (5 expected)" and so forth. Maybe I need to build
these explicitly and avoid the macros. There are a number of
algorithms in Boost.Graph for which this would be a showstopper.

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.

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.

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

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

Any thoughts at all == very much appreciated. Thanks,

Andrew Sutton

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