On Wed, Aug 13, 2008 at 11:54 AM, David Abrahams <dave@boostpro.com> 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, 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 = args.at<field::label>(); size = args.at<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.
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. Kind regards, Stjepan