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
> 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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk