Christopher Schmidt wrote:
My implementation introduces associative iterators. An associative forward sequence shall provide an iterator that allows direct mapping from the iterator (type) to the underlying element (type), key type and the actual value (type) associated with the key. I split fusion::find up in fusion::find_key and a new fusion::find. My fusion::find does not care about the associative-ness of the sequence. It searches for a plain element type. That is it returns the first iterator for which is_same<fusion::result_of::value_of<mpl::_1>, Elem> evaluates to true, or an end-iterator. fusion::find_key returns the first iterator for which is_same<fusion::result_of::key_of<mpl::_1>, Key> evaluates to true, or an end-iterator.
The compile-time evaluation of a fusion::(result_of::)find_key-invocation should scale linear to the number of elements of the sequence being searched on. The fusion::find_key implementation uses fusion::detail::static_seq_find_if, which is 4-unrolled optimized. This should be slightly faster compared to the unoptimized implementation of fusion::map<...>/set<...>::(meta_)find_impl(_const), which are plain recursive metafunctions/n-overloaded functions. The runtime performance of my port should be better if the compiler supports rvalue references. If not, there should not be a difference in any case at all. For fusion::find, the run-time performance is of course constant. The "old" implementation uses a distinct intrusive (meta-)function, analogue to find, to implement at_key. I implemented fusion::at_key based on fusion::find_key.
For more information on my port, have a look at the posts over at the development mailing list.
That's a well-thought and very nice design, Christopher! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon