cin - Why Does It Require 2 Returns?

M

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;
}
 
G

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;
 
I

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.
 
J

Juha Nieminen

Ian Collins said:
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".
 
J

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.)
 
S

Stefan Ram

Ian Collins said:
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.
 
S

Stefan Ram

James Kanze said:
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"«?
 
I

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.
 
S

Stefan Ram

Ian Collins said:
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.«
 
V

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
 
I

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?
 
S

Stefan Ram

Victor Bazarov said:
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::eek: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::eek:stream object that
flushes whenever wanted. For a simple implementation:

::std::eek: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/
 
S

Stefan Ram

Ian Collins said:
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.
 
S

Stefan Ram

One could introduce a global variable:
::std::eek: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::eek:stream & out( ::std::cout );

. Sorry!
 
I

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?
 
S

Stefan Ram

Ian Collins said:
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.
 
I

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?
 

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,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top