Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net