4

To me a stream implies that I should be able to:

  1. Put things in one end and receive it from the other end in the same order.
  2. Do these things at the same time. i.e. continuously be adding to the top of the stream and reading from the bottom.

The problem is that streams only seems to maintain a single pointer which is shared by read and write operations.

Am I just interpreting the word 'stream' differently or am I interpreting it correctly and just missing something fundamental.

(I've been using the MemoryStream type as a typical example of a general stream. Maybe there are other streams that support this?)

Improve this question
2
  • 4
    no! M$ try and trick you but there is no water involved at all! its just some computar programming doublespeak
    – Ewan
    Commented Jul 15, 2017 at 10:44
  • 1
    .NET Stream is an innovation on top of COM IStream, the latter is a part of COM structured storage, a technology used by applications across the Microsoft Office suite, etc. Wouldn't be surprised if it goes all the way back to Bill Gates. en.wikipedia.org/wiki/COM_Structured_Storage
    – rwong
    Commented Jul 15, 2017 at 18:02

2 Answers 2

Reset to default
9

Put things in one end and receive it from the other end in the same order

This would be a reasonable definition of a stream, and after all these years I still sometimes find myself falling into this mental trap for a moment. But that's not how Streams work in .NET.

Instead, think of an I/O driver: you can write to it, you can read from it, you can seek. Sometimes you can do only a subset of these things.

The implementation behind the Stream abstraction then interacts with a file, a network connection, or in the case of MemoryStream simply with a chunk of ... well, memory.

Usually it makes sense to mentally separate your Streams into read-streams and write-streams. Behind a read-stream is some functionality that allows you to read something from somewhere, while write streams allow you to write something somewhere. The real purpose of a Stream is to allow you not to think about what you're reading from or writing to.

Improve this answer
2
  • 2
    Right, it is an abstraction that can be applied to memory, files and network traffic alike. As such, the idea of pushing data in at one end (with the end being one computer) and reading that data once it has arrived at the other end (at another computer) can be a real scenario. But there would be different stream implementations at both ends. The good thing is that the application doesn't have to care whether it is reading/writing from/to a file or a network. The stream provides a universal interface.
    – Martin Maat
    Commented Jul 15, 2017 at 11:54
  • Exactly. There are many special cases that can be constructed from this. The two endpoints can even be in the same computer (even the same application), but they will require two separate stream objects and neither the read-end nor the write-end need to care where the data is coming from/going to.
    – doubleYou
    Commented Jul 15, 2017 at 12:11
6

Your interpretation applies to a queue, not a stream. A queue offers methods to add at one end (Enqueue) and take from the other end (Dequeue), in a FIFO manner.

Stream in a software sense expresses the serial, continuous character, not so much the transporting character.

Improve this answer
5
  • 2
    I'd assumed they would be good for transportation of large amounts of data without having to write it all to memory in the middle but I guess this isn't what they're for at all.
    – BanksySan
    Commented Jul 15, 2017 at 11:16
  • @BanksySan What you describe is not so much a misunderstanding of stream use, it is in fact a common application of a stream interface. It is just not the stream part providing the functionality. The stream as a concept does very little, it only offers a way to accept or to present data. In the transportation scenario there will be memory buffers and network stacks and possibly compression and encryption logic behind it that actually transport the data.
    – Martin Maat
    Commented Jul 15, 2017 at 19:09
  • 1
    that's the picture I'm getting. It seems to me to be a pretty badly designed area though. An IReadableStream, IWritableStream and ISeekableStream would have been much more intuitive and less error prone.
    – BanksySan
    Commented Jul 15, 2017 at 19:35
  • @BanksySan There may be some legacy involved. Delphi had a similar class tree with inheritence approach. When the Delphi classes were designed, the language did not support interfaces as we know them yet so abstract classes were the way to go. Delphi developer switching to .NET would ask "where are my streams?". C++ programmers would have a similar class-oriented background. These were the people to get on board. I agree if one were to start from scratch with today's technology, one would come up with a more loosely coupled, finer grained solution based on a number of pure interfaces.
    – Martin Maat
    Commented Jul 15, 2017 at 20:34
  • Thanks for the background. I like to be able to put things like this into context. It felt like legacy was to blame, but I'd not have known what it was.
    – BanksySan
    Commented Jul 15, 2017 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.