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]
> [2]

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>.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at