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