"streams"

K

Kobu

I have a question about C's abstract "streams" (that I can't seem to
FULLY understand from reading several tutorials).

Streams seems to suggest that input can be treated continously if
needed. Is this true?

So far as I know, I can only get a stream to "flow" when there is a
'\r'. At that point the '\r' is turned into a '\n' and the whole
stream is sent to some abstract area that is now only accessible to my
programs (meanwhile, other data is still piling into the input
"staging" area of the stream, waiting for another '\r' to free them-
allow them to flow).

Is this an accurate observation of C's model? Is there anyway I can
get more of a continuous stream action, instead of this '\r' triggered
stream? I am guessing there might be, but it would be a
C-extension!?!?


By the way, the first couple examples using getchar in K&R2 rely on
comparing (c=getchar()) with EOF. But, what happened to the final '\r'
that actually releases the EOF from it's input staging area? Does that
'\r' stay there waiting to release the next char that comes to the
input to the stream? Does that '\r' get converted to '\n' and sent on
it's way ready for immediate reading by an input function? Does that
'\n' disappear because of some relationship with EOF?
A link to comprehensive tutorials will be appreciated.
 
M

Mike Wahler

Kobu said:
I have a question about C's abstract "streams" (that I can't seem to
FULLY understand from reading several tutorials).

Streams seems to suggest that input can be treated continously if
needed. Is this true?

Yes, in the sense that i/o is implemented as a
continuous 'stream' of characters. ("continous"
being interruptible by an error condition or an
'end of file' indicator).
So far as I know, I can only get a stream to "flow" when there is a
'\r'.

No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.
At that point the '\r' is turned into a '\n'

Character translations (if any) are defined by a particular
implementation (probably most well known is the 'CR/LF' to/
form '\n' translation in DOS and Windows). Also note that this
'translation' is only applicable to streams opened with 'text
mode' (the default). Streams open in "binary mode" (expressed
with second argument to 'fopen()' of "b"), render the characters
as they are delivered by the attached device, with no 'translations'
at all.
and the whole
stream is sent to some abstract area that is now only accessible to my
programs (meanwhile, other data is still piling into the input
"staging" area of the stream, waiting for another '\r' to free them-
allow them to flow).

You're asking about 'buffering', which is defined by an implementation.
E.g. many/most systems where the standard stream 'stdin' is attached
to a keyboard, use 'line buffering', where the data is not sent to
the program until e.g. an 'Enter' or 'return' key is pressed. But this
is not required by the language.
Is this an accurate observation of C's model?

No, it seems to be your observation of a particular implementation
of C on a particular platform. This is admittedly a very common
behavior.
Is there anyway I can
get more of a continuous stream action, instead of this '\r' triggered
stream?

You're asking about 'nonblocking input', which is not required
(nor prohibited) by the language.
I am guessing there might be, but it would be a
C-extension!?!?

Yes, library extensions are the typical method for doing this
on platforms where it's applicable, e.g. those where 'stdin'
is attached to a line-buffered keyboard input. An implementation
or OS might also provide a facility (via another extension) to disable
'line buffering'. Check your compiler documentation.

-Mike
 
P

pete

Mike Wahler wrote:
No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.
 
M

Mike Wahler

pete said:
Text streams are composed of lines, which are newline terminated.

I wrote 'stream', not 'text stream'.

Anyway, the below excerpt from 9899 indicates to me that
a text stream may contain zero or more newline characters.

7.19.2 Streams

2 A text stream is an ordered sequence of characters composed
into lines, each line consisting of zero or more characters
plus a terminating new-line character. Whether the last line
requires a terminating new-line character is implementation-
defined.

-Mike
 
C

CBFalconer

pete said:
Text streams are composed of lines, which are newline terminated.

No, they are just sequences of characters, which should include at
least one newline character at the end. There is no intrinsic
reason to limit the count of characters between newline chars in
C. It is just a useful convention to normally keep this below 72
or 80.

The fact that routines such as fgets deliver newline separated
chunks is again not germane to what a stream is.
 
P

pete

CBFalconer said:

N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.
 
J

Joe Wright

pete said:
CBFalconer said:


N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.
Selective reading pete? Mike didn't specify text streams and the
same section you quote says..

[#3] A binary stream is an ordered sequence of characters
that can transparently record internal data. Data read in
from a binary stream shall compare equal to the data that
were earlier written out to that stream, under the same
implementation.
 
P

pete

Joe said:
CBFalconer said:
pete wrote:

Mike Wahler wrote:


No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

No


N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.
Selective reading pete?

I'm just saying that text streams are made of lines.
If you don't want know that, you don't have to.
 
M

Mike Wahler

pete said:
CBFalconer said:

N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.

You omitted:

Whether the last line requires a terminating new-line character
is implementation-defined.

-Mike
 
M

Mike Wahler

pete said:
Joe said:
CBFalconer wrote:

pete wrote:

Mike Wahler wrote:


No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

No


N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.
Selective reading pete?

I'm just saying

The ISO C standard says
that text streams are made of lines.

that a text stream may or may not contain one or more
newline characters.
If you don't want know that, you don't have to.

Back at ya. :)

-Mike
 
J

James McIninch

<posted & mailed>
I have a question about C's abstract "streams" (that I can't seem to
FULLY understand from reading several tutorials).

In C, they are FILEs.

Streams seems to suggest that input can be treated continously if
needed. Is this true?

More or less.


So far as I know, I can only get a stream to "flow" when there is a
'\r'. At that point the '\r' is turned into a '\n' and the whole
stream is sent to some abstract area that is now only accessible to my
programs (meanwhile, other data is still piling into the input
"staging" area of the stream, waiting for another '\r' to free them-
allow them to flow).

C states that input from stdin is line-buffered, but it doesn't say antyhing
about converting characters -- that's something peculiar to your
environment.

Is this an accurate observation of C's model? Is there anyway I can
get more of a continuous stream action, instead of this '\r' triggered
stream? I am guessing there might be, but it would be a
C-extension!?!?

Not in C, but chances are that for any given environment there's a way to do
it.
 
P

pete

Mike said:
pete said:
Joe said:
pete wrote:
CBFalconer wrote:

pete wrote:

Mike Wahler wrote:


No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

No


N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.

Selective reading pete?

I'm just saying

The ISO C standard says
that text streams are made of lines.

that a text stream may or may not contain one or more
newline characters.
If you don't want know that, you don't have to.

Back at ya. :)

For maximum portability of code involving text streams and text files,
one should terminate text streams with newline characters
and also bear in mind the environmental limits regarding text files.

N869
7.19.2 Streams

Environmental limits

[#7] An implementation shall support text files with lines
containing at least 254 characters, including the
terminating new-line character.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top