"Yes, I'm optimizing it for this case, because for the other cases, it will be almost as optimal than the current 2-iterator solution." That only makes sense if most of your uses of iteration will be that kind of thing. But reality is not like that at all. Most of the time, you are iterating over an actual range of actual values or manufacturing the range of values out of whole cloth. In both cases, iterator pairs have no overhead compared to a range.

And quite frankly, this problem can be fixed by allowing InputIterator to be single-access. That is, you can only do *it once between increments.Once you do that, the overhead either disappears entirely or becomes a single boolean value (to let you know whether the user accessed the iterator between increments, so that you don't have to read and discard data from your stream).

@geza: So ultimately, the C++ STL iterator model is perfectly fine.

It might need some tweaking, but with such a tweak, it will perform just as well as your example.

If my iterator is is better at InputRange, and otherwise it has similar efficiency as the c++ iterators, then I consider it better.

Note, that I'm designing an iterator hierarchy from scratch, and my little framework doesn't depend on the Standard Library at all. So I can do whatever I want.

Single-access doesn't fix current c++ iterator. Look: for (auto i=input.begin(); i!=input.end(); ++i) { ...}. Here, at i!=input.end(), iterator must read from input (to determine whether we're at the end). Because of this check, it must inevitably store the result into the iterator.