Re: [boost] [review] Fusion review begins: iterator equal_to doesn't compare values

From: Larry Evans (cppljevans_at_[hidden])
Date: 2006-05-10 16:29:59

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've not needed any runtime comparisons in any of the sequences I've implemented, 
> although I must admit I found the definition of operator== surprising to start off with. 
> 
> Can you post some code or a summary of the design you are using?
> 

Although it's not the latest code, the code here:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/indexed_types/composite_product.hpp

contains the essentials.  Briefly, the factor classes calculate the size
of a buffer to hold all the elements in the tuple as well as their
offsets.  Now, the way I've tried to use fusion's extension mechanism
is that the iterator_product<TypeIt>(void*rest)
takes mpl::begin<TypeList>::type as TypeIt where TypeList is the
TypeList used to form the tuple.  In the above code, this TypeList
is a compile-time function of TypeMap.  Then each next_impl simply
increments the rest arg to CTOR by sizeof(deref<TypeIt>::type) to
locate the next element in the tuple.  Obviously, two iterators
formed from two different tuples formed from the same TypeList
would always compare equal with the current definition of 
fusion::result_of::equal_to.  WARNING: I haven't tested that
assumption, it just seems that way from looking at the code.
I believe that would be unexpected by most users.