Re: [boost] [fusion][parameter] a solution for named parameters/parameter packs using fusion maps

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-08-13 16:15:18

On Wed, Aug 13, 2008 at 11:41 AM, David Abrahams <dave_at_[hidden]> 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