Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Accelerated C++ - Chapter 1, confusion in understanding "flushing the buffer"

Reply
Thread Tools

Accelerated C++ - Chapter 1, confusion in understanding "flushing the buffer"

 
 
arnuld
Guest
Posts: n/a
 
      03-18-2007
this is from mentioned section. i did not understand some things here:


> To avoid the overhead of writing in response to each output request, the library
> uses the buffer to accumulate the characters to be written, and flushes the buffer,
> by writing its contents to the output device, only when necessary"


it means "flushing the buffer" and "writing to output device" are SAME
thing, these are just 2 different names for the same thing.

?


> When our program writes its prompt to cout, that output goes into the buffer
> associated with the standard output stream. Next, we attempt to read from
> cin. This read flushes the cout buffer, so we are assured that our user will
> see the prompt"


1st, author is saying that our program writes its /prompt/ to cout and
then he says that /cin/ flushes the buffer and that is why user sees
the prompt.

what does he mean by "our program writes the prompt" and /cin/ helps
in the user to see the prompt ?

i think i can see the prompt every time, whether i use /cout/, cin/ or
whatever.


> Our next statement, which generates the output, explicitly instructs the
> library to flush the buffer. That statement is only slightly more complicated
> than the one that wrote the prompt. Here we write the string literal "Hello, "
> followed by the value of the string variable name, and finally by std::endl.
> Writing the value of std::endl ends the line of output, and then flushes the
> buffer, which forces the system to write to the output stream immediately.


both /cin/ and /cout/ write prompt to output device. i am utterly
confused.

 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-18-2007
* arnuld:
> this is from mentioned section. i did not understand some things here:
>
>
>> To avoid the overhead of writing in response to each output request, the library
>> uses the buffer to accumulate the characters to be written, and flushes the buffer,
>> by writing its contents to the output device, only when necessary"

>
> it means "flushing the buffer" and "writing to output device" are SAME
> thing, these are just 2 different names for the same thing.
>
> ?


Almost. Flushing the buffer involves (1) writing the characters in the
buffer to the output devices, so that they appear visually on your
screen or paper, and (2) emptying the buffer so that these characters
aren't written more times and to make room for later output.


>> When our program writes its prompt to cout, that output goes into the buffer
>> associated with the standard output stream. Next, we attempt to read from
>> cin. This read flushes the cout buffer, so we are assured that our user will
>> see the prompt"

>
> 1st, author is saying that our program writes its /prompt/ to cout and
> then he says that /cin/ flushes the buffer and that is why user sees
> the prompt.


Yes.


> what does he mean by "our program writes the prompt" and /cin/ helps
> in the user to see the prompt ?


Your source code has some statement like

std::cout << "Gimme a number!";

That's "our program writes the prompt".

The effect is just to place the text "Gimme a number!" in the output
buffer. If there had been a newline at the end, or a <<std::endl, then
the buffer would have been flushed at this point. But there isn't, so
the effect is just to accumulate text in the output buffer.

When subsequently the program executes

std::cin >> number;

std::cin first tells std::cout to flush its buffer. std::cout flushes
its buffer, and the prompt appears on your screen. std::cin inputs the
number.



> i think i can see the prompt every time, whether i use /cout/, cin/ or
> whatever.


Nope.


>> Our next statement, which generates the output, explicitly instructs the
>> library to flush the buffer. That statement is only slightly more complicated
>> than the one that wrote the prompt. Here we write the string literal "Hello, "
>> followed by the value of the string variable name, and finally by std::endl.
>> Writing the value of std::endl ends the line of output, and then flushes the
>> buffer, which forces the system to write to the output stream immediately.

>
> both /cin/ and /cout/ write prompt to output device. i am utterly
> confused.


It's std::cout that does the work. But std::cout does it in a lazy way,
accumulating text in its buffer, sort of like std::cout sits on the
toilet accumulating excrement there. Then std::cin knocks on the door
and says, hey, /I/ need to use the toilet now, flush it and get out!

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
 
arnuld
Guest
Posts: n/a
 
      03-18-2007
> On Mar 18, 11:59 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:

> * arnuld:



> Almost. Flushing the buffer involves (1) writing the characters in the
> buffer to the output devices, so that they appear visually on your
> screen or paper, and (2) emptying the buffer so that these characters
> aren't written more times and to make room for later output.


ok , thanks for *clear* explanation.


> > what does he mean by "our program writes the prompt" and /cin/ helps
> > in the user to see the prompt ?

>
> Your source code has some statement like
>
> std::cout << "Gimme a number!";
>
> That's "our program writes the prompt".


now i got it. by "prompt" you mean "Gimme a number: ".

i was thinking, "prompt" means "blinking cursor".

> The effect is just to place the text "Gimme a number!" in the output
> buffer. If there had been a newline at the end, or a <<std::endl, then
> the buffer would have been flushed at this point. But there isn't, so
> the effect is just to accumulate text in the output buffer.
>
> When subsequently the program executes
>
> std::cin >> number;
>
> std::cin first tells std::cout to flush its buffer. std::cout flushes
> its buffer, and the prompt appears on your screen. std::cin inputs the
> number.


author should have said the "text" appears on the screen, using
"prompt" as a synonym for "text" confused me.

> > i think i can see the prompt every time, whether i use /cout/, cin/ or
> > whatever.

>
> Nope.


ok, ok, you are right. as i said, i can always see the "blinking
cursor" on my screen.



> It's std::cout that does the work. But std::cout does it in a lazy way,
> accumulating text in its buffer, sort of like std::cout sits on the
> toilet accumulating excrement there. Then std::cin knocks on the door
> and says, hey, /I/ need to use the toilet now, flush it and get out!


dirty boy



just for fun


BTW, buffer is an internal data structures which holds characters, so
is it an array ?

2nd, buffer concept is used only for "efficiency" reasons ?

> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?



 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-18-2007
* arnuld:

> BTW, buffer is an internal data structures which holds characters, so
> is it an array ?


In practice yes.


> 2nd, buffer concept is used only for "efficiency" reasons ?


Yes, but...

The "but": if you are std::cout, when you write characters to a screen
that's part of the same computer you could just draw each one on the
screen as it's received for output, and then forget about it, no buffer.
But let's say the screen is an old-fashioned terminal connected to the
computer via a serial line. Displaying a character on the screen then
involves transmitting it to the terminal via the serial line, and this
is a complicated copying and conversion process, involving at least a
one-character buffer on each end of the line (in practice those buffers
are larger) -- in that situation the buffers are logically required by
the task to be accomplished, and not just optimization.

Generally, when we say "buffer" we mean a buffer that can hold more than
one character (or byte, or item), but for some problems it's important
to realize that even "un-buffered" input or output can involve
1-character buffers that cannot be avoided, because the i/o mechanism in
question isn't direct but has e.g. a transmission line.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
arnuld
Guest
Posts: n/a
 
      03-18-2007
> On Mar 18, 12:26 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:


> The "but": if you are std::cout, when you write characters to a screen
> that's part of the same computer you could just draw each one on the
> screen as it's received for output, and then forget about it, no buffer.


> But let's say the screen is an old-fashioned terminal connected to the
> computer via a serial line. Displaying a character on the screen then
> involves transmitting it to the terminal via the serial line,


are you talking about "source code on my computer" and output on "some
other computer" connected to mine with internet ?

and that "other" is trying to compile "my programme" on his computer ?

is this "buffer" concept inherited from C ?

> and this
> is a complicated copying and conversion process, involving at least a
> one-character buffer on each end of the line (in practice those buffers
> are larger) -- in that situation the buffers are logically required by
> the task to be accomplished, and not just optimization.
>
> Generally, when we say "buffer" we mean a buffer that can hold more than
> one character (or byte, or item), but for some problems it's important
> to realize that even "un-buffered" input or output can involve
> 1-character buffers that cannot be avoided, because the i/o mechanism in
> question isn't direct but has e.g. a transmission line.


i really did not understand anything here but it seems interesting



 
Reply With Quote
 
=?ISO-8859-1?Q?Erik_Wikstr=F6m?=
Guest
Posts: n/a
 
      03-18-2007
On 2007-03-18 08:41, arnuld wrote:
>> On Mar 18, 12:26 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:

>
>
>> The "but": if you are std::cout, when you write characters to a screen
>> that's part of the same computer you could just draw each one on the
>> screen as it's received for output, and then forget about it, no buffer.

>
>> But let's say the screen is an old-fashioned terminal connected to the
>> computer via a serial line. Displaying a character on the screen then
>> involves transmitting it to the terminal via the serial line,

>
> are you talking about "source code on my computer" and output on "some
> other computer" connected to mine with internet ?
>
> and that "other" is trying to compile "my programme" on his computer ?


Think of it like this, your application is running on one computer and
the person interacting with it is sitting on another computer connected
via the internet (perhaps over Telnet or SSH). Now imagine that you are
going to output 100 characters on the screen.

If you send each character on their own that would mean that you would
have to send 100 network packages, each package would need some data to
tell it where to go and so on. I think that this data can take up to 40
bytes. So sending each character alone would take 100*(40+1) bytes
(assuming one byter per character).

If you instead put all output in a buffer and wait to send until all
characters are in the buffer you only need to send 40+100 bytes.

On modern coputers it does not matter if you output the characters one
and one or all at once as long as the output is to the local monitor
since the hardware is so fast, but as you saw in the example above if a
network is involved it can be important.

> is this "buffer" concept inherited from C ?


Kind of yes, it's origionally from UNIX but C was developed on UNIX (or
rather it's standard library was a part of UNIX). On UNIX-machines of
old IO was done using terminals connected with a serial line, which were
slow so using buffering provided a noticable speedup. But you can notice
the difference even on modern hardware if you are writing large data to
files, this is almost never done without buffering for performance reasons.

--
Erik Wikström
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Questions with Accelerated C++ exercises of chapter 7 Lambda C++ 4 04-24-2008 01:52 AM
confusion while understanding prototype VJ Javascript 2 10-04-2007 07:54 PM
Accelerated C++ Chapter 15: Would you do that? Steven T. Hatton C++ 12 05-26-2005 01:01 PM
"Accelerated" certification testing programs Jameson D MCSE 2 11-26-2004 01:47 PM
Accelerated C++ Sample Solutions Martin C++ 8 10-23-2003 05:32 PM



Advertisments