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

Subject: Re: [Boost-users] [fusion] named parameter technique with fusion::map
From: Christopher Schmidt (mr.chr.schmidt_at_[hidden])
Date: 2010-11-08 14:30:08

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!

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.

Best regards,
Christopher