Boost logo

Boost Users :

From: Mats Eklund (matek994_at_[hidden])
Date: 2005-10-16 14:01:30


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
 



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net