Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #9123 > unrolled thread

cin - Why Does It Require 2 Returns?

Back to article view | Back to comp.lang.c++

Contents

  cin - Why Does It Require 2 Returns? mrc2323@cox.net (Mike Copeland) - 2011-08-20 20:49 -0700
    Re: cin - Why Does It Require 2 Returns? Geoff <geoff@invalid.invalid> - 2011-08-20 21:12 -0700
      Re: cin - Why Does It Require 2 Returns? Ian Collins <ian-news@hotmail.com> - 2011-08-21 17:21 +1200
    Re: cin - Why Does It Require 2 Returns? Ian Collins <ian-news@hotmail.com> - 2011-08-21 17:20 +1200
      Re: cin - Why Does It Require 2 Returns? Eugén Jung <contact@eugenjung.tk> - 2011-08-21 23:19 +0100
        Re: cin - Why Does It Require 2 Returns? Ian Collins <ian-news@hotmail.com> - 2011-08-22 11:38 +1200
          Re: cin - Why Does It Require 2 Returns? Ian Collins <ian-news@hotmail.com> - 2011-08-23 07:34 +1200
            Re: cin - Why Does It Require 2 Returns? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-22 15:54 -0400
            Re: cin - Why Does It Require 2 Returns? Ian Collins <ian-news@hotmail.com> - 2011-08-23 08:02 +1200
              Re: cin - Why Does It Require 2 Returns? Ian Collins <ian-news@hotmail.com> - 2011-08-23 08:39 +1200
                Re: cin - Why Does It Require 2 Returns? Ian Collins <ian-news@hotmail.com> - 2011-08-23 08:57 +1200
                  Re: cin - Why Does It Require 2 Returns? Paul <pchristor@yahoo.co.uk> - 2011-08-23 02:47 -0700
                Re: cin - Why Does It Require 2 Returns? James Kanze <james.kanze@gmail.com> - 2011-08-26 08:07 -0700
          Re: cin - Why Does It Require 2 Returns? James Kanze <james.kanze@gmail.com> - 2011-08-26 08:00 -0700
      Re: cin - Why Does It Require 2 Returns? Juha Nieminen <nospam@thanks.invalid> - 2011-08-22 06:13 +0000
        Re: cin - Why Does It Require 2 Returns? James Kanze <james.kanze@gmail.com> - 2011-08-22 10:49 -0700
          Re: cin - Why Does It Require 2 Returns? Juha Nieminen <nospam@thanks.invalid> - 2011-08-23 07:01 +0000
            Re: cin - Why Does It Require 2 Returns? Nobody <nobody@nowhere.com> - 2011-08-24 07:11 +0100
            Re: cin - Why Does It Require 2 Returns? James Kanze <james.kanze@gmail.com> - 2011-08-26 08:12 -0700

#9123 — cin - Why Does It Require 2 Returns?

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

[toc] | [next] | [standalone]

#9125

On Sat, 20 Aug 2011 20:49:48 -0700, mrc2323@cox.net (Mike Copeland)
wrote:

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

[toc] | [prev] | [next] | [standalone]

#9128

On 08/21/11 04:12 PM, Geoff wrote:
> On Sat, 20 Aug 2011 20:49:48 -0700, mrc2323@cox.net (Mike Copeland)
> wrote:
>
>>    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;

What happens if the user enters "John Doe"?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9127

On 08/21/11 03:49 PM, Mike Copeland wrote:
>     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.

>    return 0;
> }

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9141

On 21/08/11 06:20, Ian Collins wrote:
> using endl rather then \n would be better.

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

[toc] | [prev] | [next] | [standalone]

#9145

On 08/22/11 10:19 AM, Eugén Jung wrote:
> On 21/08/11 06:20, Ian Collins wrote:
>> using endl rather then \n would be better.
>
> Any particular reason (other than std::endl flushing the output buffer)?

Just flushing the output buffer.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9190

On 08/23/11 06:22 AM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> On 08/22/11 10:19 AM, Eugén Jung wrote:
>>> On 21/08/11 06:20, Ian Collins wrote:
>>>> using endl rather then \n would be better.
>>> Any particular reason (other than std::endl flushing the output buffer)?
>> 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.

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

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9195

On 8/22/2011 3:45 PM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> 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.«
>

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 do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#9196

On 08/23/11 07:45 AM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> 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.«

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?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9201

On 08/23/11 08:17 AM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> 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.

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?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9205

On 08/23/11 08:50 AM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> 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.

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?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9225

On Aug 22, 10:13 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Ian Collins <ian-n...@hotmail.com> writes:
> >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?


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.

[toc] | [prev] | [next] | [standalone]

#9341

On Aug 22, 9:50 pm, r...@zedat.fu-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

[toc] | [prev] | [next] | [standalone]

#9340

On Aug 22, 7:22 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Ian Collins <ian-n...@hotmail.com> writes:
> >On 08/22/11 10:19 AM, Eugén Jung wrote:
> >>On 21/08/11 06:20, Ian Collins wrote:
> >>>using endl rather then \n would be better.
> >>Any particular reason (other than std::endl flushing the output buffer)?
> >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.

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

[toc] | [prev] | [next] | [standalone]

#9159

Ian Collins <ian-news@hotmail.com> wrote:
> 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".

[toc] | [prev] | [next] | [standalone]

#9184

On Aug 22, 7:13 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> Ian Collins <ian-n...@hotmail.com> wrote:
> > 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.

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

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#9216

James Kanze <james.kanze@gmail.com> wrote:
> 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.)

[toc] | [prev] | [next] | [standalone]

#9274

On Tue, 23 Aug 2011 07:01:04 +0000, Juha Nieminen wrote:

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

[toc] | [prev] | [next] | [standalone]

#9342

On Aug 23, 8:01 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze <james.ka...@gmail.com> wrote:
> > 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.

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.

--
James Kanze

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web