Is there any iterator-like constructs for Streams?

[Peter Rilling]

One nice thing about collections and arrays is that they implement the
IEnumerator and IEnumerable interfaces which allow for more then one
iterator to walk the list of items without affecting the position of the
other iterators. Is there a similar thing with streams? Is there anything
in the framework that wraps a stream in such a way that the stream position
is decoupled from the stream itself?

[Jon Skeet [C# MVP]]

Peter Rilling <pe***@nospam.rilling.net> wrote:

One nice thing about collections and arrays is that they implement the
IEnumerator and IEnumerable interfaces which allow for more then one
iterator to walk the list of items without affecting the position of the
other iterators. Is there a similar thing with streams? Is there anything
in the framework that wraps a stream in such a way that the stream position
is decoupled from the stream itself?

Bear in mind that not every stream is seekable. Once you've read from a
network connection, for instance, you can't go and rewind that. The
stream would have to buffer everything. It's doable, no doubt, but I
don't believe it's provided in the framework.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel O'Connell [C# MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Peter Rilling <pe***@nospam.rilling.net> wrote:

One nice thing about collections and arrays is that they implement the
IEnumerator and IEnumerable interfaces which allow for more then one
iterator to walk the list of items without affecting the position of the
other iterators. Is there a similar thing with streams? Is there
anything
in the framework that wraps a stream in such a way that the stream
position
is decoupled from the stream itself?
Bear in mind that not every stream is seekable. Once you've read from a
network connection, for instance, you can't go and rewind that. The
stream would have to buffer everything. It's doable, no doubt, but I
don't believe it's provided in the framework.

Definatly not something that will work in general, although I could see
value in designing the object model to support it. Perhaps instead of basing
it on Stream, the framework should have defined a subclass SeekableStream or
whatnot which would support seeking, length changing, etc instead of
defining Seek on Stream(from which FileStream and MemoryStream, for example,
would derive). It'd not be difficult to write this kind of implementation
using streams that can seek, you would just have to use the CanSeek property
to determine seekability instead of relying on the compiler to catch the
mistake. Infact that might be a fun thing to write to play with C#
iterators, I've been looking for a project to play with them on anyway(ought
to be easy to write an iterator which produces a generic IEnumerator which
reads data structures from a stream, not so useful but something to do).

Its unfortunate that streams were designed as they were, with the three can
properties instead being inheritance based, but its understandable due to
the lack of multiple inheritance(although, the C++ implementation of streams
iss pretty horrible, much of it due to overuse of MI). I suppose an
interface based system could have been written, but it would have been ugly.
Atleast a seperation of a basic stream which reads and writes linearly and a
stream that supports seeking would have been appropriate, IMHO. Streams are,
at the most, *often* seekable but the non-seekable case is common enough(and
annoying enough) that I have trouble attributing it as a standard behaviour
of a stream even if I can't think of a library that doesn't support it.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too