From: Scott Woods (scottw_at_[hidden])
Date: 2007-06-20 15:34:26
----- Original Message -----
From: "Jeremy Maitin-Shepard" <jbms_at_[hidden]>
Sent: Wednesday, June 20, 2007 7:47 PM
Subject: Re: [boost] [rfc] I/O Library Design
> Steven Siloti <ssiloti_at_[hidden]> writes:
> 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?).
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
Whether an STL interface to traditional application streams is an
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
printing debug and taking input of test-run parameteres, it might not.
Maybe another part of the matrix, i.e. not exclusively iterator-based?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk