On Wed, Aug 13, 2008 at 11:41 AM, David Abrahams <dave@boostpro.com> wrote:
on Wed Aug 13 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Stjepan Rajko:
function_taking_both( label("hello") & size(1) );
FWIW, I've been using this in a context where I needed "arbitrary" argument lists and it works. It has the advantage that the caller only needs to know about label and size, the eventual callee only needs to know about the arguments it recognizes and can ignore the rest, and the intermediate layers can pass everything downstream as-is without knowing about anything.
Why is everyone hand-rolling the functionality we already have in Boost.Parameter?
I can give you my reasons, at least :-) The major deciding factor was that I thought that Boost.Parameter-ized constructors required a base class to dispatch to. Looking back at the Boost.Parameters docs, here is what gave me that impression (section 2.3): "The lack of a "delegating constructor" feature in C++ (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf) limits somewhat the quality of interface this library can provide for defining parameter-enabled constructors. The usual workaround for a lack of constructor delegation applies: one must factor the common logic into a base class." Note the word "must". Reading that entire section, I found nothing to change that impression. Another reason is that I found the following syntax intimidating: BOOST_PARAMETER_FUNCTION( (void), // 1. parenthesized return type depth_first_search, // 2. name of the function template tag, // 3. namespace of tag types (required (graph, *) ) // 4. one required parameter, and (optional // four optional parameters, with defaults (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index,graph)) (in_out(color_map), *, default_color_map(num_vertices(graph), index_map) ) ) ) It looks like a very powerful syntax, but also something that would be easy to trip over (remembering the order of macro parameters, for example). Perhaps it is easy to just write what the macro would expand to by hand, but after deciding not to use the library because of the first reason I listed, I didn't really feel motivated to look into it further. Finally, I was concerned about the impact on compile time, which I've seen mentioned on the list a few times. Whether what I have now is any faster is yet to be tested. Stjepan