Streams

[valaris]

I am not understanding what a stream is. I have read that unbuffered I/O is when the data comes straight from the os/kernel to your program, and buffered I/O stores the data in an intermediary buffer before doing something with it. (I think..)

However it says that streams are associated only with buffered I/O as a link between the device and software?

*What exactly is a stream
*how is it related to buffered/unbuffered IO ?

Thanks.

[tabstop]

Streams are are how other physical devices are conceptualized in C. C doesn't know the hardware details of how stdin and stdout work; and C doesn't want to know, either. So C models them as a stream: it's out there, somewhere and when you want to read in some input you go out with a bucket and grab some. You're always grabbing the "oldest" material (that is, things are read in the order they get typed), and output always happens in order too. In that sense, you can think of "stream" = "queue".

[valaris]

So does a stream take only from Unbuffered I/O? It can't take unbuffered straight from the system? Are my ideas of buffered/unbuffered I/O even right? I guess my question is where is the stream dipping this "bucket" in each case of I/O ?

Thanks

[tabstop]

Most streams are buffered; certainly stdin and stdout are, and any FILE that you happen to have running around is almost always buffered. Standard says:

When a stream is unbuffered, characters are intended to appear from the source or at the
destination as soon as possible. Otherwise characters may be accumulated and
transmitted to or from the host environment as a block. When a stream is fully buffered,
characters are intended to be transmitted to or from the host environment as a block when
a buffer is filled. When a stream is line buffered, characters are intended to be
transmitted to or from the host environment as a block when a new-line character is
encountered. Furthermore, characters are intended to be transmitted as a block to the host
environment when a buffer is filled, when input is requested on an unbuffered stream, or
when input is requested on a line buffered stream that requires the transmission of
characters from the host environment. Support for these characteristics is
implementation-defined, and may be affected via the setbuf and setvbuf functions.

So: depends on the implementation. The implementation should have set up a buffer for you for stdin and stdout -- if you ask for input, it will look at its buffer first, and if that's empty (or doesn't have enough) then it goes bother the system. (I'm guessing here, since I don't actually know that, but that's what I would expect.)

[valaris]

Oh ok much thanks. It is starting to make sense now. I was especially interested in streams because somebody had told me there are no streams in C. And it seems to be there indeed are streams in C...

[tabstop]

There are streams in C, but we don't have iostream and stringstream and fstream (we have stdin and FILE, which are streams but don't have stream in the name).

[valaris]

Yes thankyou And i read on and finally found a suitable definition in the book which I think mirrors yours that really sums it up.

"A stream provides a full-duplex path between a user process and a device driver. There is no need for a stream to talk to an actual hardware device"

[MK27]

here's my two cents:

• Streams are very much a unix rooted concept. The three basic streams, in or out of C, would be "stdin" (standard input) "stdout" (standard output) and stderr (usually synonymous w/ stdout).
• While they usually relate to hardware (input from keyboard, output to screen), they do not necessarily or exactly. For example, I assume the main reason for having a "stderr" is that it can be redirected and seperated from stdout.
• "I have read that unbuffered I/O is when the data comes straight from the os/kernel to your program, and buffered I/O stores the data in an intermediary buffer before doing something with it." I think in the context of programming, the difference between "unbuffered" and "buffered" would be (respectively) the difference between data recieved byte by byte and data recieved in larger blocks. For example, you can work with text by character or you can work with text by line/string. In either case, the data is being manipulated in physical memory by the OS/CPU (a "buffer" is conceptual).
• This all becomes important when a buffer may have to fill up before it's released, eg. a three letter word may leave an eight byte buffer hanging, like the remainder in long division. I don't know if or when this becomes much of an issue in C, but it can be elsewhere.

#include <stdio.h>

int main () {
        int chr;
        while (chr = fgetc(stdin)) putchar(chr);
}

See streams flowing thru this one? Water is the way...