Steven Siloti <ssiloti@gmail.com> 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