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/inde... 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.