[boost] Re: problem with new iterators in 1.31 Release candidate # 2

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-02-01 11:28:38

Robert Ramey <ramey_at_[hidden]> writes:

> I have a problem with the latest version of the new iterators.
> This is illustrated in the following example.
>
> #include <strstream>
> #include <iterator>
> #include <boost/iterator/counting_iterator.hpp>
>
> main(){
> 	std::istrstream is("abcdefg");
> 	typedef boost::counting_iterator<std::istream_iterator<char> > ci;
> 	const ci end = std::istream_iterator<char>();  // note the const !!!

I don't see why the const should be relevant.

>From looking at the code for counting iterator it seems to me that it
is implemented for non - random access iterators by incrementing
one iterator until it equals the other and return the number of times
the increment occured.  (I concede that I've had difficulty following
the implementation so I could be wrong).  So if one of the iterators
is const - that one can't be the one that's incremented.

> 	ci begin = std::istream_iterator<char>(is);

Hmm, the implicit conversions from istream_iterator to the
counting_iterator above are troubling.  I think those constructors
should be explicit.

Hmmm - From looking at the documentation and the code, I get 
absolutly no indication that the counting iterator requires a randome
access iterator.  In fact, looking at the code suggests that there
is code especially included to handle any forward transversal 
iterators.  And the first invocation below DOES work - I can't
believe that's an accident.

> 	unsigned int size;
>
> 	// the following should fail at compilation ?

Why?  OK, maybe it would be better to make it fail because the
iterator is not in fact a random-access iterator.

> 	// in fact it compiles are returns a value of -7 !!!
> 	size = begin - end;
>
> 	// the following should compile and return a value of 7
> 	// in fact, it compiles but goes into an infinite loop
> 	size = end - begin;
> }

My mistake - I wrongly presumed that only the second iterator would be
incremented and since its const it should fail.  It looks like the code
intends to select which iterator to increment depending on const.
So this first case looks ok to me now.

I don't see why you think the first should compile but the second
should not.  If they're not random-access iterators, it seems to me
that there's no reason you should be able to subtract them in any
order.  If they were random-access iterators, it would be unreasonable
to expect the compiler to detect which one had an earlier position
and disallow one subtraction.

So my position is that both compile (as they should).  The first works
as one would expect while the second results in an infinite loop.  I'm
sorry but I don't see how this can be correct.

> Note that this problem did not appear with the first release
> candidate.
>
> Also, if one follows the links from the main documentation page, one
> is directed to the documentation of the old iterators.  This is
> extremely confusing.  This has been pointed out before.

That's a serious problem which I'll fix immediately.

Robert Ramey