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

From: Steven Siloti (ssiloti_at_[hidden])
Date: 2007-06-20 17:47:38

Scott Woods wrote:
> ----- 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
>   
> 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?
>
>   
I did not mean to imply that iterators should be the exclusive means of 
access, my thinking at the moment just happened to depart down that 
tangent. What I really meant to say is that I would like to see an I/O 
library who's lowest level uses generic programming and extends on 
concepts used in the STL rather than the OOP style used with IOStreams 
and the Java I/O library. Higher level operations like formatted output 
could be implemented on top of this foundation.

Going further down the iterators tangent I could imagine having the 
ability to create block level iterators that deal in arrays of elements 
for when one would want to use an iterator to do bulk processing.

Steven Siloti