Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-08-14 07:17:37


Aleksey Gurtovoy wrote:

> 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

This is also one of the reasons why Fusion deviates a bit from MPL.
In Fusion, we have both at<N> and at_key<K>.

Regards,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk