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