From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2007-06-20 03:47:20
Steven Siloti <ssiloti_at_[hidden]> writes:
> As long as we're talking about a new I/O library for C++ I'll go ahead
> and give my $0.02.
> I think some consideration should be given to designing an I/O library
> on the basis of STL concepts. After all, files aren't really streams,
> they're arrays of bytes (or a similar basic element). Thus it seems more
> natural to model a class representing a file after std::vector rather
> than some stream concept. In fact I've done exactly this using memory
> mapped file I/O as part of another project where I needed to store many
> Bidirectional Iterators to various files and it worked quite well.
It would certainly be a requirement to provide an iterator/range
interface to a stream. The boost iostreams library also has the concept
of a direct stream, that is accessed by an iterator range (or maybe with
the requirement that the iterators be pointers), which may be a useful
concept to integrate into a new I/O library.
The issue with relying on an iterator interface exclusively is the lack
of efficiency: without a buffer (and in general, there need not be one),
each dereference of the input iterator, or assignment to the output
iterator, would require a separate call to the underlying source, which
might mean a read/write system call. Furthermore, because the iterator
interface requires that only a single element is processed at a time,
applying type erasure/runtime polymorphism to the iterator types is much
less efficient, since a virtual function call would be needed for every
element, whereas with a stream interface, an entire array of elements
can be processed using only a single virtual function call.
-- Jeremy Maitin-Shepard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk