[mpl][fusion] Issues in the mpl/fusion interface
Hi all, I am writing some code which uses MPL and fusion together, and in general I am happy with their interoperability. However, I have stumbled on a few areas in which functionality I expected was missing, or where expressions I expected to work did not. All of these issues have workarounds, but I'd appreciate some input on whether the problem is with the libraries, or with my expectations. 1. mpl::pair and fusion::pair Fusion sequences are conforming MPL sequences, and MPL sequences can be transmuted into fusion sequences. However, the same is not true of their pair classes. I feel that fusion::pair ought to conform to some "MPL pair" concept such that: - I can access its types by the same 'first' and 'second' members as in mpl::pair - mpl::first and mpl::second metafunctions should work against it For instance, I'd like to be able to extract a sequence of key types from a map: // OK! typedef mpl::map<mpl::pair<int, char>, mpl::pair<bool, short> > m1; typedef mpl::transform< m1, mpl::first<mpl::placeholders::_1>, mpl::back_inserter<mpl::vector<> > >::type keys1; // Not OK! typedef fusion::map<fusion::pair<int, char>, fusion::pair<bool, short> > m2; typedef mpl::transform< m2, mpl::first<mpl::placeholders::_1>, mpl::back_inserter<mpl::vector<> > >::type keys2; // OK, but requires different code for mpl and fusion maps typedef mpl::transform< m2, fusion::result_of::first<mpl::placeholders::_1>, mpl::back_inserter<mpl::vector<> > >::type keys3; Also, I feel there should be a canned way to translate mpl::pair into fusion::pair. fusion::result_of::as_pair? 2. mpl::map and fusion::map This code works nicely: typedef mpl::vector<int, char, bool> v1; typedef fusion::result_of::as_vector<v1>::type v2; v2 v(1, 'a', false); However, this does not: typedef mpl::map<mpl::pair<int, char>, mpl::pair<bool, short> > m1; typedef fusion::result_of::as_map<m1>::type m2; m2 m('a', 3); The type 'm2' ends up as fusion::map<mpl::pair<int, char>, mpl::pair<bool, short> >, which clearly is no good. I feel that as_map should automatically translate mpl::pair to fusion::pair so that the result is a usable container. Please let me know if I am barking up the wrong tree, or whether these seem like useful features to anyone else. If there is consensus that they are useful, I would be interested in developing patches for them. Thanks, -Gabe
On 8/9/2011 6:12 AM, Gabriel Redner wrote:
Hi all,
I am writing some code which uses MPL and fusion together, and in general I am happy with their interoperability. However, I have stumbled on a few areas in which functionality I expected was missing, or where expressions I expected to work did not. All of these issues have workarounds, but I'd appreciate some input on whether the problem is with the libraries, or with my expectations.
1. mpl::pair and fusion::pair
Fusion sequences are conforming MPL sequences, and MPL sequences can be transmuted into fusion sequences. However, the same is not true of their pair classes. I feel that fusion::pair ought to conform to some "MPL pair" concept such that:
- I can access its types by the same 'first' and 'second' members as in mpl::pair - mpl::first and mpl::second metafunctions should work against it
That sounds reasonable.
Also, I feel there should be a canned way to translate mpl::pair into fusion::pair. fusion::result_of::as_pair?
Ok. Sounds good.
2. mpl::map and fusion::map
This code works nicely:
typedef mpl::vector<int, char, bool> v1; typedef fusion::result_of::as_vector<v1>::type v2; v2 v(1, 'a', false);
However, this does not:
typedef mpl::map<mpl::pair<int, char>, mpl::pair<bool, short> > m1; typedef fusion::result_of::as_map<m1>::type m2; m2 m('a', 3);
The type 'm2' ends up as fusion::map<mpl::pair<int, char>, mpl::pair<bool, short> >, which clearly is no good. I feel that as_map should automatically translate mpl::pair to fusion::pair so that the result is a usable container.
Please let me know if I am barking up the wrong tree, or whether these seem like useful features to anyone else. If there is consensus that they are useful, I would be interested in developing patches for them.
All these sound reasonable. I'd definitely welcome a patch, but I have to insist on docs too. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
Hi Joel, OK, thanks for the responses. When I have some free time I'll look into implementing this, and I'm happy to write docs. -Gabe
participants (2)
-
Gabriel Redner
-
Joel de Guzman