Re: [Boost-users] [fusion] named parameter technique with fusion::map

Subject: Re: [Boost-users] [fusion] named parameter technique with fusion::map
From: Larry Evans (cppljevans_at_[hidden])
Date: 2010-11-08 14:41:42

On 11/08/10 13:30, Christopher Schmidt wrote:
> Larry Evans schrieb:
>> On 11/08/10 06:55, Larry Evans wrote:
>> [snip]
> [snip]
>>> BTW, just read:
>>>
>>>   http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html
>>>     /fusion/notes.html#fusion.notes.overloaded_functions
>>>
>>> which says:
>>>
>>>   There is an overloaded function, f(k), for each key type k.
>>>   The compiler chooses the appropriate function given a key, k.
>>>
>>> which is exactly the method used in named_component_ctor.cpp,
>>> where the overloaded function is arg.
>>
>> It's not obvious to me, after looking at:
>>
>>   key_of_impl.hpp
>>   value_of_impl.hpp
>>
>> in boost/fusion/container/map/detail where this overloaded
>> function, f, is located.  (Of course I assume it's not named
>> f, but something like value_of...).  Could someone point it out?
> 
> Larry,
> 
> thanks for your work!
> 

Sure.  It's interesting.

> I am responsible for that change. The old implementation, that is the
> implementation up to revision 40392, did lookup values by key type via
> one single overloaded function:
> 
> https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/container/map/detail/at_key_impl.hpp?rev=40392#L42
> https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/container/map/detail/lookup_key.hpp?rev=40392#L81
> 
> I ditched that when I merged associative iterators from my port back to
> the trunk. I did some benchmarking back then. IIRC, overloaded value
> lookup did worse than the unrolled value lookup.
> Here is the original post:
> 
> http://article.gmane.org/gmane.comp.lib.boost.user/52510
> 
> Another benchmark:
> 
> http://article.gmane.org/gmane.comp.lib.boost.devel/194407
> 
> I did not use gcc 4.5 and clang back then, though. I will try to get my
> benchmarks running again and try your implementation.
> 
> Regarding the actual topic - reordering on construction has been
> requested before. Actually we already have a ticket that was opened 3
> years ago:
> 
> https://svn.boost.org/trac/boost/ticket/1404
> 
> I think implementing reordering in fusion::map and fusion::set is not a
> good idea. At any rate reordering per se does increase compile time and
> does not fit to the underlying concept of random access (sequence).
> On the other hand, reordering via fusion::nview is simple. I think it
> might be a good idea to get this documented, as an example maybe, or in
> a "useful bits&pieces"-section.

Thanks Christopher; however, I must be misunderstanding what Alfredo
wanted.  I just thought he wanted named parameters.  I thought the
example he gave:

> One question: Why I can not interchange the order of p and q in the
> last call, after all it is a map at the library could in principle
> differentiate the pairs? making it possible to call an unordered named
> parameter. e.g.
> cout << H(
>  map<pair<p, double>, pair<q, double> >(
>     make_pair<q>(2.),  // was p
>     make_pair<p>(1.)   // was q
>  )
> );

in his OP illustrated that, and I thought my last code example
did just that:

        typedef
      map_default
      < mpl::pair<mpl::int_<1>,ti<1> >
      , mpl::pair<mpl::int_<2>,ti<2> >
      , mpl::pair<mpl::int_<3>,ti<3> >
      >
    map_def_ti1_3_t;
...
      map_def_ti1_3_t
    map_def_ti1_3_val2_1
    ( fusion::pair<mpl::int_<2>,ti<2> >(2)
    , fusion::pair<mpl::int_<1>,ti<1> >(1)
    );

What am I missing?

Thanks much for the explanation and history.  That sort of detail
sure makes it easier to understand why the code is the way
it is.

-regards,
Larry