----- Original Message ----- From: "Jeremy Maitin-Shepard" <jbms@cmu.edu> To: <boost@lists.boost.org> Sent: Wednesday, June 20, 2007 7:47 PM Subject: Re: [boost] [rfc] I/O Library Design
Steven Siloti <ssiloti@gmail.com> writes:
[snip]
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.
These issues sound a lot like issues solved in serialization. I have also created extensions to STL such that an input iterator representing an open file could be passed to standard algorithms. Off-hand I cant see why an iterator could not be crafted, that attached itself to a standard stream (shucks, doesnt this exist already?). Immediately you would have an "STL interface" to streams where a single input operation (e.g. *itr) does not necessarily result in a system call (buffering in the standard stream). Whether an STL interface to traditional application streams is an improvement, is a little murky. What do we currently do with these streams and how would iterator-based access improve the quality of my app? If you were implementing all the *nix utilities it would be cool. If you were printing debug and taking input of test-run parameteres, it might not. Maybe another part of the matrix, i.e. not exclusively iterator-based?