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
> With Boost.Parameter it would look like:
> class named_constructable
> // 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk