David Abrahams wrote:
"Neal D. Becker" <ndbecker2@verizon.net> writes:
Is the preference for the former case over the latter intentional?
Not particularly; it just worked out that way. I guess in the interest of efficiency it'd be better to take the one that doesn't involve a unary minus.
This caused some surprise when I tried to re-implement my cycle_iterator_adapator (a kind of circular buffer adaptor).
std::copy (b, a, ...) will do: template<typename _RandomAccessIter, typename _OutputIter> inline _OutputIter __copy(_RandomAccessIter __first, _RandomAccessIter __last, _OutputIter __result, random_access_iterator_tag) { typedef typename iterator_traits<_RandomAccessIter>::difference_type _Distance; for (_Distance __n = __last - __first; __n > 0; --__n) { *__result = *__first; ++__first; ++__result; } return __result; }
As I implemented cycle_iterator_adaptor distance_to, it was expecting that given iterators [a,b], you probably want a positive distance from a to b,
Correct, if b is reachable by applying increments to a.
but the way iterator_adaptors is implemented, it wants a negative distance.
Huh? What do you mean "it wants"?
Sorry for the confusion. I'm implementing a kind of circular buffer. You can reach from a->b or b->a with a positive increment. If the user asks to std::copy (a, b, c), it winds up calling template <class Facade1, class Facade2> static typename Facade1::difference_type distance_from( Facade1 const& f1, Facade2 const& f2, mpl::true_) { return -f1.distance_to(f2); } So my distance_to has to be reversed: difference_type distance_to(circle_iterator<BaseIterator> const& y) const { difference_type d = y.base_reference()-base_reference(); if (d < 0) return d; else return d - allocated; } The returned value from distance_to has to be negative, that's what I meant by "it wants a negative distance", because it will then invert the sign.