Boost Users :
From: David Abrahams (dave_at_[hidden])
Date: 2006-06-27 13:23:44
Yuval Ronen <ronen_yuval_at_[hidden]> writes:
> 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
>> The 'front's availability is dictated by the Forward Sequence concept
> Then perhaps the Forward Sequence concept should not require
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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net