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

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/de... https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/container/map/de...

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 >( 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,ti<1> > , mpl::pair,ti<2> > , mpl::pair,ti<3> > > map_def_ti1_3_t; ... map_def_ti1_3_t map_def_ti1_3_val2_1 ( fusion::pair,ti<2> >(2) , fusion::pair,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