cin - Why Does It Require 2 Returns?

[Stefan Ram]

So you agree that using std::endl is preferable to '\n' when outputting
text to be read by a user?

Can you post a specific C++ program, where ::std::endl is
advantageous in this case?

 

[Juha Nieminen]

Unless the programmer understands buffering, and what it does,
he should use std::endl. It's just too hard to debug a program
when you don't know where it crashed, because part of your
output hasn't appeared.

I don't think one should rely on the output of std::cout for debugging
purposes anyways. If adding debug prints, std::cerr should be used instead
of std::cout. std::cerr will flush after each *character* (ok, I don't know
if that's by standard, but at least the last time I checked with gcc it
does). This is of course horribly slow, but good for debugging.

And of course a good debugger will tell you where the program crashed.
(Ok, not always, if the crash was caused by memory corruption which
manifests itself in a completely unrelated part of the program. But
debug prints won't help in that situation much either.)

 

[Paul]

  Can you post a specific C++ program, where ::std::endl is
  advantageous in this case?

If you are outputing a string literal, then its often easier to simply
add \n.
Its lazy typing but also perfectly acceptable in these little example
programs.
I don't see any requirment to flush the buffer in this example.
Whether or not endl should be used as good practise all the time is a
choice for the individual.

 

[Nobody]

I don't think one should rely on the output of std::cout for debugging
purposes anyways. If adding debug prints, std::cerr should be used instead
of std::cout. std::cerr will flush after each *character* (ok, I don't know
if that's by standard, but at least the last time I checked with gcc it
does). This is of course horribly slow, but good for debugging.

I'm not entirely sure how cout/cerr relate to stdout/stderr; however:

ISO C requires that initially stderr is not fully buffered while stdout is
fully buffered if and only if it can be determined not to refer to an
interactive device.

POSIX says the same thing, but the conventional Unix behaviour is that
initially stderr is unbuffered, while stdout is line buffered if it refers
to a tty and fully buffered otherwise.

Note that "unbuffered" doesn't actually mean the same thing as
"flush after each character"; the latter implies a write() per
byte. Ultimately, "unbuffered" just means the stream doesn't have a
persistent user-space buffer associated with it, so there's no way for a
write operation on a stream to be deferred past the point that the
function returns.

 

[James Kanze]

Flushing takes time. That's exactly why buffering was
invented. So, in C++, one flushes only when it is necessary.
Flushing ::std::cout immediately before a program ends
is not necessary.

And how else do you know that the output has correctly worked.
Every program I've ever written which outputs to std::cout
flushes the output immediately before finishing, and tests the
error status of std::cout after the flush, in order to output an
error message and return EXIT_FAILURE if the output hasn't
worked. I'd consider it an error is a program didn't do this.

With regards to the chose of std::endl or '\n', it depends. The
default choice is std::endl, so that output will appear, even if
the program later crashes (in which case, the final output is an
important hint as to where the problem lies). On the other
hand, if you're outputting a number of lines, with no
significant intermediate calculations, it's perfectly fine to
use '\n'. And of course, if the program does actually run to
slowly, you do what you have to do to speed it up. (But that
falls under the heading of optimization.)

 

[James Kanze]

On Aug 22, 9:50 pm, (e-mail address removed)-berlin.de (Stefan Ram) wrote:

[...]

C++ is hard, large, and complex but fast. One uses C++, when
programs need to run fast. Otherwise, other programming languages
are more efficient in terms of programming effort and provide
better security.

The most frequent reason for using C++ is because it results in
lower development cost than less powerful languages. Large
applications are, by their very nature, complex. C++ moves some
of that complexity into the language, where it is formallized,
and only have to be mastered once. Other languages leave it in
the application.

Console dialogs with users do not need a fast programming
language, since they wait for user input most of the time
anyways.

It's true that console dialogs are typically very small
programs. Which means that they're written directly in the
native shell, or Python (or Perl, if you're really a masochist).
But console dialogs are also good as a learning experience, and
if you're learning C++, writing the console dialogs in Python
won't help much. And if you're learning C++, you probably want
to learn the best practices. And the best practice in C++ is to
use std::endl except in cases where you're sure that it's safe
not to.

 

[James Kanze]

I don't think one should rely on the output of std::cout for debugging
purposes anyways. If adding debug prints, std::cerr should be used instead
of std::cout.

If you're adding debug prints, yes. std::cerr is the usual and
correct destination. If your program unexpectedlyh crashes when
handling client data, however, it's often very helpful to see
just how far it got.

std::cerr will flush after each *character* (ok, I don't know
if that's by standard, but at least the last time I checked with gcc it
does). This is of course horribly slow, but good for debugging.

No ostream will flush after each character, unless you turn off
buffering. std::cerr will flush after every << operator.

And of course a good debugger will tell you where the program crashed.
(Ok, not always, if the crash was caused by memory corruption which
manifests itself in a completely unrelated part of the program. But
debug prints won't help in that situation much either.)

Agreed, but how much output has already occured can often be a
good additional hint.