Scott Woods wrote:
----- 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
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