From: Gunter Winkler (guwi17_at_[hidden])
Date: 2005-06-26 05:27:34
Am Freitag, 24. Juni 2005 22:52 schrieb Vardan Akopian:
> On 6/24/05, Gunter Winkler <guwi17_at_[hidden]> wrote:
> > I tracked the bug down until matrix_expression.hpp:2121-2131 where
> > matrix_binary::const_iterator1::operator += ( n )
> > is defined as
> > const_iterator1 &operator += (difference_type n) {
> > i_ += n, it1_ += n, it2_ += n;
> > return *this;
> > }
> > which may move the iterator (far) behind the end if n is too large.
> > I suggest changing this to n times calling operator ++ () which
> > already checks the bounds (depending on the iterator type.) Or it
> > may move the iterator if the index is already larger than i_.
>
> Wouldn't it be too inefficient though, to do the check n times?
> I would think, we might wonna do the other way around, i.e. have a
> function increment(tag, differnece_type n), which does the
> appropriate check for each iterator type in the general case, then
> call this from operator+= and operator++.
What do you think about adding an advance_to(idx) (rewind_to(idx))
funtion to all ublas iterators, that move an iterator to (or just
behind if not found) the value that has index idx? The implementation
could be done by either using find(..) or have a more clever
implementation if available. And another advantage is that if we
combine more iterators in a complex expression, each iterator uses its
fastest movement.
mfg
Gunter