Hi, I was just wondering why fusion (and mpl) don't include multi-maps or multi-sets. Are they unnecessary at compile time? Are they too trivial? Do they conceptually not work? Thanks, John Femiani.
AMDG John C. Femiani wrote:
I was just wondering why fusion (and mpl) don't include multi-maps or multi-sets. Are they unnecessary at compile time? Are they too trivial? Do they conceptually not work?
The easiest way to implement a multimap is in terms of an ordinary map. In a fusion/mpl map the key is a type and lookup uses overload resolution. This means that there is necessarily a 1-1 correspondence between keys and values. The obvious way to implement a multimap is to make the value a container. Because of the function nature of fusion/mpl this would be like template<class M, class K, class V> struct multimap_insert_existing { typedef typename insert<typename erase_key<M, K>::type, pair<K, typename push_back<typename at<M, K>::type, V>::type> > type; }; template<class M, class K, class V> struct multimap_insert_new { typedef typename insert<M, pair<K, vector1<V> > > type; }; template<class M, class T> struct multimap_insert { typedef typename T::first key_type; typedef typename T::second value_type; typedef typename eval_if<has_key<M, key_type>, multimap_insert_existing<M, key_type_value_type>, multimap_insert_new<M, key_type, value_type> >::type type; }; In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
John C. Femiani wrote:
I was just wondering why fusion (and mpl) don't include multi-maps or multi-sets. Are they unnecessary at compile time? Are they too trivial? Do they conceptually not work?
The easiest way to implement a multimap is in terms of an ordinary map. In a fusion/mpl map the key is a type and lookup uses overload resolution. This means that there is necessarily a 1-1 correspondence between keys and values. I would expect a multimap to contain pairs, and to provide an iterator range or sequence of like keys via an 'equal_range' function (like unordered_multimap).
I also just noticed there is no 'equal_range' query metafunction, although there is a 'lower_bound' and 'upper_bound'.
The obvious way to implement a multimap is to make the value a container. Because of the function nature of fusion/mpl this would be like
template<class M, class K, class V> struct multimap_insert_existing { typedef typename insert<typename erase_key<M, K>::type, pair<K, typename push_back<typename at<M, K>::type, V>::type> > type; };
<more code> So it is feasible, but the authors just wanted to keep the scope limited? That works for me; I've been toying with that idea anyhow but I wanted to make sure I was not going waste my time. Thanks, --John
John C. Femiani wrote:
Steven Watanabe wrote:
AMDG
John C. Femiani wrote:
I was just wondering why fusion (and mpl) don't include multi-maps or multi-sets. Are they unnecessary at compile time? Are they too trivial? Do they conceptually not work?
The easiest way to implement a multimap is in terms of an ordinary map. In a fusion/mpl map the key is a type and lookup uses overload resolution. This means that there is necessarily a 1-1 correspondence between keys and values. I would expect a multimap to contain pairs, and to provide an iterator range or sequence of like keys via an 'equal_range' function (like unordered_multimap).
I also just noticed there is no 'equal_range' query metafunction, although there is a 'lower_bound' and 'upper_bound'.
The obvious way to implement a multimap is to make the value a container. Because of the function nature of fusion/mpl this would be like
template<class M, class K, class V> struct multimap_insert_existing { typedef typename insert<typename erase_key<M, K>::type, pair<K, typename push_back<typename at<M, K>::type, V>::type> > type; };
<more code>
So it is feasible, but the authors just wanted to keep the scope limited?
That works for me; I've been toying with that idea anyhow but I wanted to make sure I was not going waste my time.
As for Fusion, contribution is always welcome :-) Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
participants (3)
-
Joel de Guzman -
John C. Femiani -
Steven Watanabe