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

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-13 14:54:44

on Wed Aug 13 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:

> 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.

Okay, so what are you trying to accomplish?

>>> 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.  

It's just the same syntax you use normally, but with an extra set of
parentheses.

> BTW, I just extended the fusion-based solution to also support that
> syntax.

Well, at the time we redesigned the library, I encouraged Daniel Wallin
to look into whether we could gain anything by using fusion, because the
fundamental data structure we use is like a fusion map.  He said we
couldn't gain anything significant, and at the time I took his word for
it.  The entire code corresponding to fusion::map is contained in
boost/parameter/aux_/arg_list.hpp.  The rest of the library consists
primarily of functionality you're not providing.

>>> 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.

The latter is already the case in Boost.Parameter.

> 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.

I'm just saying, if you're going to make comparisons of the two
libraries, they should be informed comparisons and not speculation.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com