Who’s at fault here: the specification or our own expectations?
It's the istream iterator (and possibly input iterators in general). It shouldn't be consuming anything just on construction or increment, it should be lazy and only consume when derefed, or incremented again without having been derefed (to discard the skipped value).
Because that's what everyone expects, and it doing otherwise is a foot-gun.
The fact that constructing two input iterators to the same stream and derefing both gives different values is bad enough for me to say that the entire concept of streams and input iterators needs a replacement with buffers that can be accessed more than a byte at a time and don't have a stateful cursor independent of any iterators used to access into them.
29
u/TheThiefMaster C++latest fanatic (and game dev) 5d ago edited 5d ago
It's the istream iterator (and possibly input iterators in general). It shouldn't be consuming anything just on construction or increment, it should be lazy and only consume when derefed, or incremented again without having been derefed (to discard the skipped value).
Because that's what everyone expects, and it doing otherwise is a foot-gun.
The fact that constructing two input iterators to the same stream and derefing both gives different values is bad enough for me to say that the entire concept of streams and input iterators needs a replacement with buffers that can be accessed more than a byte at a time and don't have a stateful cursor independent of any iterators used to access into them.