On Wed, Aug 13, 2008 at 2:03 PM, David Abrahams <dave@boostpro.com> 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@boostpro.com> 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