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

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
>>>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