Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-10 21:15:45

Joel de Guzman wrote:
> dan marsden wrote:
>>> On 05/10/2006 03:04 PM, dan marsden wrote:
>>>> Larry Evans
>>>>> The boost/fusion/iterator/equal_to.hpp has:
>>>>> operator==(Iter1 const&, Iter2 const&)
>>>>> {
>>>>> return result_of::equal_to<Iter1, Iter2>::value;
>>>>> }
>>>>> Obviously only the types are compared and not the values.
>>>>> Shouldn't the values be compared as well? I've got my own
>>> [snip]
>>>> I believe that the position of a fusion iterator must be encoded in
>>>> the information available at compile. This is needed for fusion sequences
>>>> to serve as conforming MPL sequences (and probably various other things).
>>> OK, maybe I misunderstood. I thought that since operator* returns a
>>> value instead of a type (obviously), that two iterators would be equal
>>> only when they were the same length and each value returned by operator*
>>> was equal. Is that not the case?
>> I believe 2 fusion iterators should compare equal iff they refer to the same position
>> within the same sequence. Comparing iterators from different sequences should be
>> documented to result in undefined behaviour. I'll tighten up the documentation in this
>> area.
>> Joel, am I correct in the above?
> Yes.

The issue here is (if it's not clear yet) that the terminal
condition of all fusion algorithms should be known at compile time.
IOTW, all fusion sequences should be traversable at compile time.

If this is not the case, then (to list a few):
1) the sequences will not be traversable by MPL
2) we can't create views (e.g. iterator_range): views, like all
sequences, have a fixed length that should be known at compile time.

This constraint is also the very reason why Fusion algorithms are
so tight and fast. The compilers can optimize the recursions into
tight unrolled inline functions.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at