For std::copy_n, getNext's return value can be ignored. And if getNext is inlined, its return value calculation can be optimized away. so it doesn't matter too much. For the value_type comment, getNext() could return a pair: a bool and a return value. My question is a more of a conceptual question. Java has a separate hasNext(), next() function, C++ has two-iterators model, both of them incapable doing (if I'm not mistaken) one of the simplest iteration: reading line from a file the most simplest way. "My" version can do it, and so I still don't see any drawbacks of this method.

"my" version has this drawback too: "the fact that you cannot increment without accessing.". If this is important, then a bool skip() method can be added.

Basically, the intent of my question was that I'd like to design an iterator which is the "best" available, that's why I'm trying to collect all pros/cons of each method.

@geza: "For std::copy_n, getNext's return value can be ignored." But it still has to be generated. And therefore, the test has to be done. "I'd like to design an iterator which is the "best" available" "best" is in the eye of the beholder. I don't see your example as being any better objectively than standard iterators, and it is worse for many use cases, as outlined. A simpler way to read lines from a file is for(const auto &line : line_reader(stream)). Where line_reader extracts a range of lines. It works fine with the Iterator model.

Yes, but that's why I said that if it is inlined, then it will be optimized away. If it is not inline, then it doesn't matter too much anyway. But, if it matters, then we can add this functionality too in the iterator: getForcedNext(), or something like that. There has to be a reason that every language has its own differing iterators, C++ will be (hopefully) extended with ranges, etc. I do think that there exist a "best", or almost the "best" iterator... Besides, "my" iterator can be used to implement C++'s InputRange (so it can be used conveniently), but the converse is not true.

@geza: "Besides, "my" iterator can be used to implement C++'s InputRange (so it can be used conveniently), but the converse is not true." Nonsense. You can implement your thing API on top of an iterator pair. See, your problem is that your concept doesn't implement "iterators"; it implements iteration. There's a difference, and I pointed that out in my post. "Iteration" requires knowledge of where it terminates; "iterators" do not. It's the lower-level construct.

How can you implement it "lightweightly"? As I see, begin() needs to read an element, so it can be compared to end(). So it needs to store the read element into the iterator.

@geza: You never said "lightweightly". Also, it's only "lightweight" by comparison for iteration over things that don't have an end-point. As I pointed out in my post, for iteration over a "begin/end" pairs, your equivalent (which is functionally just a range) will be heavier weight than regular iterators if you don't need the "end". That's why iterator is the base type and ranges are built on top of them. It is lighter-weight.

@geza: Basically, you're optimizing your system for the case of Iterator/DefaultConstructibleSentinel.

Sorry, I haven't mentioned it in my comments here, but I mentioned it in the question. If you add the read object into the iterator, it can be much more heavyweight. For example, if you read lines, then it will contain a string (allocation happen, etc.). For "my" iterator, it doesn't have to. 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. The 2-iterator solution usually more heavyweight (or equal) then the range one (because you have to store container info for both of the iterators).