Yuval Ronen
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'?
Well, there's a default implementation that works for anything providing begin, so I suppose it doesn't need to be part of the concept from that point of view. However, some sequences might provide a more efficient one, and generic code that wants to use front should be able to count on it.
What is it good for?
Isn't it obvious? Getting the first element of the sequence.
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 there is meaning.
Of course, everything I say is analogous to std containers, and should sound familiar.
Not really; we don't have any standard unordered containers.
'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.
It's not just a shortcut; it can be optimized for specific sequences.
Providing 'front' without 'back' sounds stridently asymmetric to me.
See any singly-linked list implementation.
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...
The problem is that to me this looks like a one-off confusion. If the joint view docs clearly state that the two sequences are concatenated, I don't see why anyone else would be confused. I never loved the name "joint_view" though. Maybe "concat_view" would be clearer. -- Dave Abrahams Boost Consulting www.boost-consulting.com