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

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-08-13 12:12:54

On Wed, Aug 13, 2008 at 8:43 AM, David Abrahams <dave_at_[hidden]> wrote:
>
> Yes, but this chaining interface is the same one used by the old
> Boost.Graph named parameter interface (which incidentally I suggested),
> and has a nasty coupling problem that we explicitly wanted to avoid: all
> the possible parameter names need to be known in one place, and must be
> available to all the functions that may use said parameters.

I fixed that problem (see my recent reply to Paul Bristow and
referenced code snippets therein).

>>
>> Compared to Boost.Parameter, I have a hunch that the Fusion approach
>> would be faster to compile (haven't tested that though),
>
> Why don't you do some testing if you think so?  Don't forget to make sure
> your library supports all the same features as Boost.Parameter.  Making
> it pass the Boost.Parameter test suite would be a good start.
>

Testing is a good suggestion, but I don't have the time right now to
do that :-)  I'm not necessarily interested in replicating all
Boost.Parameter features.  I'm quite happy with the fusion-based
solution as a simple one.

>> and is a little bit less convoluted (esp. for certain cases like
>> constructors using named parameters).
>
> Boost.Parameter supports an equivalent approach to the one you're using
> here, if you want to use it, which avoids the need for a base class to
> dispatch to.

Oh, cool, I didn't know that.  In my recent scan through
Boost.Parameter docs I only noticed the approach that required the
base class to dispatch to.  It was only a quick scan though.

> The problem is that, like your approach, the syntax is
> slightly unnatural:
>
>  SomeClass((label="hello", size=size_one))
>

Seems like a reasonable syntax.  BTW, I just extended the fusion-based
solution to also support that syntax.

>
>> I've never used Boost.Parameter so I'm not sure what other comparisons
>> might apply.
>
> Then isn't it a bit early to be talking about the superiority of this
> approach?
>

I didn't claim superiority - I only gave indications of two things
where I think it might have an advantage.  The source code is approx
140 lines of straightforward use of fusion, and no preprocessor magic
(I leave that to fusion :-)) - also, the generic version mentioned in
my reply to Paul Bristow makes it very easy to add new fields.
Granted, I haven't taken a look at Boost.Parameter source code, and my
"knowledge" of its used is based on memory from reading the docs and
various discussions on the list where people have commented on it.

Thanks for taking a look,

Stjepan