From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2007-08-14 07:00:16
> I have two mpl maps like this:
> map<pair<int_<1>, int_<42> >,
> pair<int_<2>, int_<43> >,
> pair<int_<3>, int_<44> >
> > Map1;
> 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 .
'joint_view' of two maps is simply a Forward Sequence , 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.
-- Aleksey Gurtovoy MetaCommunications Engineering
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk