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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-06-26 03:51:44

Yuval Ronen writes:
> I spent some time reading the mpl docs, and I have a few questions
> about mpl::set and mpl::map.
>
> 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).
Personally, I don't think that providing it is any more weird than
providing 'begin'.

> But if I'm wrong, and 'front' is in place, then where is 'back'?

'front' is a shortcut for 'deref< begin<s>::type >', which is
guaranteed to be an O(1) operation for any MPL sequence; 'back', on
the other hand, can be O(1) only for bidirectional sequences, and
neither 'set' nor 'map' is one of them.

> 2. Where's multiset and multimap? 

There is a 'multiset' sketch that you mention below that needs
finishing; 'multimap' is non-existent. Contributions are welcome!

> In the boost/mpl directory I see something about multiset, but no
> real boost/mpl/multiset.hpp header, and there's absolutely nothing
> about multimap.
>
> 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.

HTH,
-- 
Aleksey Gurtovoy
MetaCommunications Engineering