Wait for <Enter>-key

[Denis Hierstein]

I need a function, witch make a break in a for-loop and wait for the
<enter>-key ... when I use Pascal I just use the Read; or the
ReadLn;-function, then the loop stop as long as the user push the
<Enter>-key.

 

[John Harrison]

I need a function, witch make a break in a for-loop and wait for the
<enter>-key ... when I use Pascal I just use the Read; or the
ReadLn;-function, then the loop stop as long as the user push the
<Enter>-key.

You cannot wait for any key in standard C++. Standard C++ has no support
for keyboards.

You can do this

#include <string>
#include <iostream>

std::string dummy;
std::getline(std::cin, dummy);

which will read a line of text from the standard input. This might be what
you want but that depends on exactly what you are trying to do.

john

 

[hall]

You cannot wait for any key in standard C++. Standard C++ has no support
for keyboards.

You can do this

#include <string>
#include <iostream>

std::string dummy;
std::getline(std::cin, dummy);

which will read a line of text from the standard input. This might be what
you want but that depends on exactly what you are trying to do.

john

Out of curiosity, is this behaviour guarantied by the standard? Is
getline forced (by the standard) to read a string that is never used or
is it possible for the compiler to remove this as an optimization?

Does the same answer hold for other ways of reading a string (or other
data) from a stream object (eg [int i; std::cin >>i] , [string s; cin >>
s]) )?

The reason for this question is my previous experiences with Fortran,
where optimization may even remove parts of code that actually is doing
(at least) output to file or screen.

/hall

 

[Karl Heinz Buchegger]

Out of curiosity, is this behaviour guarantied by the standard? Is
getline forced (by the standard) to read a string that is never used or
is it possible for the compiler to remove this as an optimization?

The compiler can't remove this as it violates principle #1 in optimization:
The compiler can optimize away anything it wants, as long as the programms
behaviour does not change.

There is one exception to that rule, which is explicitely mentioned in the
C++ standard: return value optimization, where the compiler is allowed to
optimize away a call to the copy constructor even if that cctor has
side effects. But ASFAIK this is the only exception.

 

[Immanuel Albrecht]

Out of curiosity, is this behaviour guarantied by the standard? Is
getline forced (by the standard) to read a string that is never used
or is it possible for the compiler to remove this as an optimization?

It is not allowed to remove the read by optimization, because it changes
the whole effect that your program has (i.e. no keyboard input read->
different system state).

If so, you could never read a dummy line that contains no valuable
information for your program.

Does the same answer hold for other ways of reading a string (or other
data) from a stream object (eg [int i; std::cin >>i] , [string s; cin

s]) )?

Of course. You optimizer will not decide whether your code makes sense
and erase the code if not. That's what the programmers are for.

The reason for this question is my previous experiences with Fortran,
where optimization may even remove parts of code that actually is
doing (at least) output to file or screen.

I guess your optimizer then was broken. I do not think it is legal to
remove program output even in Fortran. Its like you write a program
calculating pi to the 4050493493...4993..32nd digit and then your
optimizer doesn't make the output. See?

 

[Rolf Magnus]

The compiler can't remove this as it violates principle #1 in
optimization: The compiler can optimize away anything it wants, as
long as the programms behaviour does not change.

How would the behaviour of the program change?

 

[Rolf Magnus]

How would the behaviour of the program change?

Sorry, I might have misunderstood. I thought, "hall" was asking if the
compiler could optimize the string away, i.e. instead of copying the
line into a string and then throwing that string away, just remove the
line from cin without copying it anywhere.

 

[Attila Feher]

Rolf Magnus wrote:
[SNIP]

Sorry, I might have misunderstood. I thought, "hall" was asking if the
compiler could optimize the string away, i.e. instead of copying the
line into a string and then throwing that string away, just remove the
line from cin without copying it anywhere.

In theory (if the std::string functionalty used by the code is all inline)
the compiler _may_ remove the string creation, but of course not the input.
I personally doubt if any compiler is clever enough to do that. Why? It
would then need to create an unnamed static string as a replacement so that
it can still write the characters somewhere - since it cannot optimize away
that part of the getline function, even if it is inline (one definition
rule). I wonder what the standard says about an optimization like this...
Anyways it is probably possible to trick it using ignore and a "hand made"
static variable - but I am absolutely beginner in iostreams so I better stop
guessing.

Attila

 

[Pete]

Denis

This might help a little. you just need to make sure that when you call the
function, the standard input stream is empty.

cheers
Pete


#include<iostream>

int main()
{
while(true)
{
std::cout << "Press enter key";

if(std::cin.peek() == '\n') // looks to see if the next character in the
standard input stream is enter
{
std::cin.ignore(1000,'\n'); // clear the stream
break; // break the loop
}
else
{
std::cin.ignore(1000, '\n');
continue;
}
}

std::cout << "while broken";

return 0;
}

 

[hall]

Out of curiosity, is this behaviour guarantied by the standard? Is
getline forced (by the standard) to read a string that is never used
or is it possible for the compiler to remove this as an optimization?

It is not allowed to remove the read by optimization, because it changes
the whole effect that your program has (i.e. no keyboard input read->
different system state).

If so, you could never read a dummy line that contains no valuable
information for your program.

Does the same answer hold for other ways of reading a string (or other
data) from a stream object (eg [int i; std::cin >>i] , [string s; cin

s]) )?

Of course. You optimizer will not decide whether your code makes sense
and erase the code if not. That's what the programmers are for.

unless you are using Fortran

I guess your optimizer then was broken. I do not think it is legal to
remove program output even in Fortran. Its like you write a program
calculating pi to the 4050493493...4993..32nd digit and then your
optimizer doesn't make the output. See?

Actually, no. The compiler was not broken. Optimizing can be(*) a rather
violent process in Fortran and may remove functionality in the code,
resulting in missing outputs, ignored function calls etc. And this is of
course why I wanted to make sure that C++ did not support anything like
this in its standard.

However, code such as
for (unsigned long int i=0; i<255^4; i++){
float f=... // silly calculations affecting variables
// only within the for-loop scope
}
should be removed by any decent optimization algorithm in C++ (and
programmer to, for that matter), right?


/hall



(*)perhaps I should add that how far the optimization is allowed to go
in Fortran can be controlled by setting the options for it. It doesn't
go wild on your code everytime ;-)

 

[hall]

Rolf Magnus wrote:




Sorry, I might have misunderstood. I thought, "hall" was asking if the
compiler could optimize the string away, i.e. instead of copying the
line into a string and then throwing that string away, just remove the
line from cin without copying it anywhere.

No, I was worried that some compiler might remove the entire
[std::cin << var] part of the code, thus making John's suggestion for
how to induce a pause into the program useless.

Optimizing away the actual string is perhaps not so useful. The time it
takes for the user to press enter and read this from the keyboard buffer
into the C++ stream is probably much longer than the time to create and
destroy the string object, and for memory, who has the patience to input
a string long enough to take up more than a fraction of a modern
computers memory ;-) ?

anyway, thanks for sharing your wisdom (all of you)

/hall

 

[Immanuel Albrecht]

Actually, no. The compiler was not broken. Optimizing can be(*) a
rather violent process in Fortran and may remove functionality in the
code, resulting in missing outputs, ignored function calls etc. And
this is of course why I wanted to make sure that C++ did not support
anything like this in its standard.

Well at least, there would be a switch which should read "break
optimizer"

However, code such as
for (unsigned long int i=0; i<255^4; i++){

255^4 means 251, ^ is bitwise-xor! (Not power as one
might think.).

float f=... // silly calculations affecting variables
// only within the for-loop scope
}

should be removed by any decent optimization algorithm in C++ (and
programmer to, for that matter), right?

Depends on what else is done within the for scope. As long as it works
the same it probably would.

But do not think that a C++ optimizer will do your thinking as the
Fortran one would have. At least I haven't seen one that will kill
variables that are not used but that will get a value.