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

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-08-13 17:25:07

On Wed, Aug 13, 2008 at 2:03 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> on Wed Aug 13 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
>
>> On Wed, Aug 13, 2008 at 11:54 AM, David Abrahams <dave_at_[hidden]> wrote:
>>>
>>> Okay, so what are you trying to accomplish?
>>>
>>
>> Being able to have named parameters and not using Boost.Parameter.
>
> Well, then I'm afraid that Boost.Parameter can never help you :-)
>

:-)  I should say, that was what I was trying to accomplish when I
wrote the fusion-based utility this morning.  As you've gone through
my rationale and explained how it was mostly unfounded (and thank you
for the clarifications), the "not using Boost.Parameter" part can go
away.

>
> With Boost.Parameter it would look like:
>
>  class named_constructable
>  {
>  public:
>      // a macro could extend the number of parameters if desired
>      template<typename FM0, typename FM1>
>      named_constructable(const FM0 &a0, const FM1 &a1)
>      {
>        label = (a0,a1)[_label];
>        size = (a0,a1)[_size];
>      }
>      std::string label;
>      int size;
>  };
>

If I had seen that in the docs first instead of the recommended
approach I would have given Boost.Parameter a try.  Instead, I
happened to look at a page that told me I can't do something like that
code snippet (the section 2.3 "must" fiasco).

> But if you use the recommended method of building constructors,
> Boost.Parameter also supports:
>
>  named_constructable x0("hello", 1);
>  named_constructable x0("hello", _size=1);
>  named_constructable x0(_label="hello", _size=1);
>  named_constructable x0(_size=1, _label="hello");
>
> and in this case (using deduced parameters), even
>
>  named_constructable x0(1, "hello");
>

This is really cool, but I'm fine with just named parameters, and
prefer that over using the macro.

>>> I'm just saying, if you're going to make comparisons of the two
>>> libraries, they should be informed comparisons and not speculation.
>>
>> Well, I tried to make sure that my speculations were qualified as such
>> (and I consider speculation to be a valid component of discussion).
>> If my speculations came across as assertions, I apologize.
>
> They didn't, but I did find your presumption that we hadn't already gone
> over this ground in designing the library rather... premature.
>

I don't know where I presumed that :-)  It just turned out that the
documentation (erroneously) indicated that I couldn't do something I
wanted to do using Boost.Parameter, so I gave up and tried
implementing something different.

Stjepan