[boost] [Boost.Parameter] questions and advice

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

Boost,

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
asutton_at_[hidden]