Hello,

does anybody know whether there is something fundamentally wrong with designing an istream

iterator that conforms with the forward, or even random access, iterator concepts? The

std::istream_iterator conforms only with the simplest input iterator concept (stream need not

support positioning).

If a stream supports positioning, I cannot see why this should not work. If a streamable T

has variable size on stream, we could do forward iteration, and if T has a known constant size

on the stream, we could do random access iteration, right?!

Since I haven’t found any previous work in this direction on the web, I suspect there is a catch...

(performance?)

The only disadvantage I see, is that such iterators would have a rather different semantics from

the std::(i)stream_iterator:s (equality etc), and that to create an end-iterator in the random access

case, we cannot just rely on the default constructor, but need to pass in the stream, perhaps

prepositioned at end.

The original problem is to log/write data-records T on a persistant device, for which a

std::stream(buf) interface is available. A reason for using the streambuf interface is that the log

can support wrap-around functionality by simply using an intermediate streambuf that cares for

necessary wrap-around functionality only, and otherwise just forwards transported characters to the

device’s streambuf. An enhanced std::istream_iterator would provide the log user with a

convenient interface for reading records T out of the log.

Thanks for any hints!

/Mats