Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-13 17:03:20

on Wed Aug 13 2008, "Stjepan Rajko" <> wrote:

> On Wed, Aug 13, 2008 at 11:54 AM, David Abrahams <dave_at_[hidden]> wrote:
>>> 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?
> Being able to have named parameters and not using Boost.Parameter.

Well, then I'm afraid that Boost.Parameter can never help you :-)

>> 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.
>>From what you're saying, it could be that our approaches are similar
> but using a different map type. Using the fusion-based approach, I
> can do this:
> 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)
> {
> // this could be done lazily...
> map<field::label, field::size>::type args = a0 & a1;
> label =<field::label>();
> size =<field::size>();
> }
> std::string label;
> int size;
> };
> BOOST_AUTO_TEST_CASE( test_multi_param_construction )
> {
> named_constructable constructed(label_ = "hello", size_ = 1);
> BOOST_CHECK_EQUAL(constructed.label, "hello");
> BOOST_CHECK_EQUAL(constructed.size, 1);
> }
> If our approaches are similar, that would suggest Boost.Parameter
> could do the same.

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;

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");

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

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at