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

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-02-02 00:45:35

Dave Abrahams wrote:

>Robert Ramey wrote:

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

>Yeah, it's a mistake.  It shouldn't use distance, but operator-.
>That way neither one of your subtractions would compile.

>From the documentation:
counting_iterator requirements
The Incrementable argument shall be Copy Constructible and Assignable.
If iterator_category is convertible to forward_iterator_tag or forward_traversal_tag, the following must be well-formed:
Incrementable i, j;
++i;         // pre-increment
i == j;      // operator equal

Suppose I had used a different iterator as a base - not
an input iterartor but some kind of forward transveral iterator.
Would that have been ok?

Now if I understand correctly? the only difference between the single pass transveral
and forward transversal is the ability to "rewind".  As far as I can see
the ability doesn't affect the requirement stated above.  Are sure that
the requirement isn't too strong.  The fact that it "accidently" works seems
to suggest this.

from the nomenclature, example, other "counting iterators", and common
sense,  I would expect an example such as the one I presented to
function as I expected.  And in fact it did in the previous release candidate.

That is, its natural to expect the following to function

std::fstream is;
std::input_iterator begin(is), end();

int filesize = end - begin;

Can the design and implement (of off course document) be adjusted
to permit this?  If such a seemingly natural usage is not possible, it
should be trapped at compile time (as you suggested) and the reason
why it can't be supported described in the documentation.

Robert Ramey