cin - Why Does It Require 2 Returns?

[Mike Copeland]

In the following program, I must press "return" twice when I enter
the string data. Why is that? TIA

#include <iostream>
#include <string>
using namespace std;

int main ()
{
string mystr = "";
cout << "What's your name? ";
getline (cin, mystr);
cout << "Hello " << mystr << ".\n";
return 0;
}

 

[Geoff]

In the following program, I must press "return" twice when I enter
the string data. Why is that? TIA

#include <iostream>
#include <string>
using namespace std;

int main ()
{
string mystr = "";
cout << "What's your name? ";
getline (cin, mystr);
cout << "Hello " << mystr << ".\n";
return 0;
}

Because you're using it wrong?

cin >> mystr;

 

[Ian Collins]

In the following program, I must press "return" twice when I enter
the string data. Why is that? TIA

The same reason you asked the question twice

You shouldn't.

#include<iostream>
#include<string>
using namespace std;

int main ()
{
string mystr = "";

You don't need to initialise the string, it defaults to empty.

cout<< "What's your name? ";
getline (cin, mystr);
cout<< "Hello "<< mystr<< ".\n";

using endl rather then \n would be better.

 

[Ian Collins]

Because you're using it wrong?

cin>> mystr;

What happens if the user enters "John Doe"?

 

[Eugén Jung]

using endl rather then \n would be better.

Any particular reason (other than std::endl flushing the output buffer)?

 

[Ian Collins]

Any particular reason (other than std::endl flushing the output buffer)?

Just flushing the output buffer.

 

[Juha Nieminen]

using endl rather then \n would be better.

That's a bad advise to give just like that. Newbies will then start using
it *everywhere* and have their programs heavy in I/O slow down to a crawl.

When you give the advise, you have to explain *why*. Also explain when
it's better to use "\n".

 

[James Kanze]

That's a bad advise to give just like that. Newbies will then
start using it *everywhere* and have their programs heavy in
I/O slow down to a crawl.

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.

When you give the advise, you have to explain *why*. Also
explain when it's better to use "\n".

The only time it's "better" to use "\n" is if your program runs
too slowly otherwise. There are a number of times where it
really doesn't matter, and I'll use "\n" in the middle of a
number of closely spaced output, especially if I'm outputting
several lines in a single expression. (But then, I'm not really
a newby when it comes to ostream, so I can allow myself this
sort of luxury.)

 

[Stefan Ram]

Just flushing the output buffer.

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.

 

[Stefan Ram]

Unless the programmer understands buffering, and what it does,
he should use std::endl.

If a person does not understand buffering, and what it does,
he might not yet be called a »C++ programmer«.

The only time it's "better" to use "\n" is if your program runs
too slowly otherwise.

So, whenever I have to print a string variable, I would
have to split it into segments at each »\n« that is part
of the string, and then print those segments and ::std::eol
after each segment, in order not »to use "\n"«?

 

[Ian Collins]

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.

Until the program grows and the user wonders why the line does not appear.

 

[Stefan Ram]

Until the program grows and the user wonders why the line does not appear.

A: »Why should I use X in this program?«
B: »You do not actually need it in this program.
But if you would write another program, you would need it.
So you'd better start using it right now, should your
program ever be changed somehow into that other program.«

A: »Why should I take the drug X?«
B: »Well you do not need it right now. But if you ever should
develop the condition S, you would need it. Therefore, you
should better start to take it now, so that you will not
forget to take it, if you ever develop that condition.
Even, if the drug makes your movements become
a little bit slower now.«

 

[Victor Bazarov]

A: »Why should I use X in this program?«
B: »You do not actually need it in this program.
But if you would write another program, you would need it.
So you'd better start using it right now, should your
program ever be changed somehow into that other program.«

A: »Why should I take the drug X?«
B: »Well you do not need it right now. But if you ever should
develop the condition S, you would need it. Therefore, you
should better start to take it now, so that you will not
forget to take it, if you ever develop that condition.
Even, if the drug makes your movements become
a little bit slower now.«

To summarise all recommendations, in a debug version every output should
be followed by a flush (otherwise the output can be lost when debugging
with breakpoints or due to a crash), and any time the designer of the
program expects the user to want to see the output, some kind of flush
needs to happen, especially when the user input is required. Correct?
The latter is often taken care of by synchronising intput and output.
And the former could be done based on timer.

For debugging, some kind of built-in automatic flushing after every
output would be very handy. OTOH, when debugging I/O buffering one
should explicitly disable the automatic flushing...

Any other times when a flush would be necessary or ill-advised?

V

 

[Ian Collins]

A: »Why should I use X in this program?«
B: »You do not actually need it in this program.
But if you would write another program, you would need it.
So you'd better start using it right now, should your
program ever be changed somehow into that other program.«

When interacting with a user, have you ever seen a case where a flush is
detrimental to the operation of a program?

Sure too many flushes may cause performance penalties when wring
gigabytes of data to a file, but when interacting with the user?

 

[Stefan Ram]

For debugging, some kind of built-in automatic flushing after every
output would be very handy. OTOH, when debugging I/O buffering one
should explicitly disable the automatic flushing...

Does, »after every output« mean to have 6 flushes in

::std::cout << "alpha\n"

(first flush after the output of the 'a', Second flush
after the output of the 'l', ...)?

Or do you mean »for each use of <<", so that

::std::cout << "al" << "pha\n"

would flush twice?

One could introduce a global variable:

::std:stream const out( ::std::cout );

and then always use »out« for outputs (instead of
::std::cout). Then, - during debugging - it could be
redefined to refer to some custom ::std:stream object that
flushes whenever wanted. For a simple implementation:

::std:stream const out( ::std::cerr );

, since IIRC, »::std::cerr« flushes more often than
»::std::cout«.

PS: See also:

http://www.cplusplus.com/reference/iostream/manipulators/unitbuf/

 

[Stefan Ram]

When interacting with a user, have you ever seen a case where a flush is
detrimental to the operation of a program?

Real-world local C++-applications are either operated from
the command line or have a GUI. When they are operated from
the command line, they are controlled by command-line
arguments and options and then might write output to the
console. They might even read input from ::std::cin, when
they behave as a »filter«, but they hardly ever start a dialog
with the user where they alternately ask a question and then
expect a user input (today, GUIs are used for such programs).

Programs that start such a dialog in a text console seem to
be found predominantly in C++ tutorials or text books, nowadays.

 

[Stefan Ram]

One could introduce a global variable:
::std:stream const out( ::std::cout );

Oops! I took this from my own tutorial, but I have
overlooked that there it was an example for an error!

The correct declaration has to be

::std:stream & out( ::std::cout );

. Sorry!

 

[Ian Collins]

Real-world local C++-applications are either operated from
the command line or have a GUI. When they are operated from
the command line, they are controlled by command-line
arguments and options and then might write output to the
console.

Or a log. There a few things more frustrating than a truncated or
incomplete entry in a log file after a crash.

They might even read input from ::std::cin, when
they behave as a »filter«, but they hardly ever start a dialog
with the user where they alternately ask a question and then
expect a user input (today, GUIs are used for such programs).

That doesn't answer my question, when interacting with a user, have you
ever seen a case where a flush is detrimental to the operation of a program?

Programs that start such a dialog in a text console seem to
be found predominantly in C++ tutorials or text books, nowadays.

Wasn't that exactly what the original post was, a tutorial example?

 

[Stefan Ram]

That doesn't answer my question, when interacting with a user, have you
ever seen a case where a flush is detrimental to the operation of a program?

I have not investigated this question.

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.

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

Since C++ is already optimized to enable the best run-time
efficiency, even when this means, that programming becomes
more difficult, usually a programming styles that cares for
run-time efficiency is more adopted to the language.

 

[Ian Collins]

I have not investigated this question.

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.

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

Since C++ is already optimized to enable the best run-time
efficiency, even when this means, that programming becomes
more difficult, usually a programming styles that cares for
run-time efficiency is more adopted to the language.

That's a very long winded way of saying you haven't.

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