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

From: Scott Woods (scottw_at_[hidden])
Date: 2007-06-20 15:34:26

----- Original Message ----- 
From: "Jeremy Maitin-Shepard" <jbms_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, June 20, 2007 7:47 PM
Subject: Re: [boost] [rfc] I/O Library Design

> Steven Siloti <ssiloti_at_[hidden]> 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?