Re: [boost] [rfc] I/O Library Design

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.

[snip]

-- 
Jeremy Maitin-Shepard