Hi Martin,
I have two mpl maps like this:
typedef map<pair<int_<1>, int_<42> >, pair<int_<2>, int_<43> >, pair<int_<3>, int_<44> >
Map1;
typedef map<pair<int_<4>, int_<44> >, pair<int_<5>, int_<45> >, pair<int_<6>, int_<46> >
Map2;
I try to join them using "joint_view" as follows:
typedef joint_view<Map1, Map2>::type JointMap;
which works fine. Then I do
std::cout << at<JointMap, int_<2> >::type::value << "\n";
which gives the following compiler error:
error: 'value' is not a member of 'boost::mpl::pair<mpl_::int_<3>, mpl_::int_<44> >'
I tried this with gcc 3.4.6 and 4.2 under Linux, Boost version is 1.34.0. It seems "at" returns the entry after the searched entry, and not only the right half, but the complete pair.
Has anybody got any hints on this? To me it looks like a bug in MPL, but I might be wrong.
Both sides of this behavior steam from nongenericity of the 'at' metafunction, which treats Associated Sequences differently from "plain" Forward Sequences [1]. 'joint_view' of two maps is simply a Forward Sequence [2], which changes the 'at' semantics from a value lookup in the associative sequence to an equivalent of 'deref< advance< begin<s>::type,n >::type
::type'. Thus the result you observed: 'at<JointMap, int_<2> >::type' simply returns JointMap's third element.
This can be definitely argued to be a design bug. However, suppose that requesting the map's value by key was spelled differently, say, 'get'. Well, even in this case, unless the 'joint_view' of two Associated Sequences becomes in an Associated Sequence as well, applying 'get' to JointMap still won't work -- although you'd most likely get an error instead of a puzzling result. All in all, to get the behavior you want with the current library you need to actually merge two maps into a third one. [1] http://boost.org/libs/mpl/doc/refmanual/at.html [2] http://boost.org/libs/mpl/doc/refmanual/joint-view.html HTH, -- Aleksey Gurtovoy MetaCommunications Engineering