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