Re: [Boost-users] [mpl] a few questions about set and map

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-06-27 04:31:25

Aleksey Gurtovoy wrote:
>>1. The docs assert there is a 'front' algorithm for set and
>>map. This sounds weird to me, as the order of the types is them
>>unspecified.
> 
> 
> The 'front's availability is dictated by the Forward Sequence concept
> requirements
> (http://www.boost.org/libs/mpl/doc/refmanual/forward-sequence.html).

Then perhaps the Forward Sequence concept should not require 'front'? 
What is it good for?

> Personally, I don't think that providing it is any more weird than
> providing 'begin'.

'begin/end' are needed in order to iterate the sequence, and therefore 
required for for any sequence. 'front', as I see it (which I hope is the 
right way to see it) is only relevant for sequences where the order of 
the elements is user-defined, i.e. vector and list. Where the order is 
not guaranteed (set/map), there is no meaning to 'front'.

Of course, everything I say is analogous to std containers, and should 
sound familiar.

> 'front' is a shortcut for 'deref< begin<s>::type >'

The fact that 'front' is just a shortcut for 'deref< begin<s>::type >' 
is another reason why it's not really needed for Forward Sequence.

Providing 'front' without 'back' sounds stridently asymmetric to me.

>>3. The docs say that the size of joint_view is the arithmetic sum of the 
>>sizes of the sequences of which it's composed. 
> 
> Yep.
> 
>>Is that true also in the case of set/map?
> 
> Yes.
> 
>>For an mpl newbie it sounds reasonable that it will 
>>removed duplicates and might end up with a size that is smaller than the 
>>sum of its components. If it's not, then it sounds quite useless to use 
>>it for set/map.
> 
> Informally, 'joint_view' provides us a way to iterate through the
> elements of two sequences without paying the upfront cost of their
> concatenation. While technically it could be specialized for
> associative sequences to eliminate duplicates, it would (a) break
> genericity of the adaptor and (b) deprive us of the basic,
> unspecialized functionality. If I was to implement the suggested
> behavior, I'd go for a separate 'unique_view' component which would
> have none of the downsides and an advantage of being applicable to
> non-associative sequences as well.

Then I think a word of warning in the docs about using it with set/map 
is a good idea. People like me could get confused...

> HTH

Yes it does!
Thanks.