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@cs.kent.edu