I ran this code
char c;
cin >> c;
cout << c;
cin >> c;
cout << c;
and wrote to the console ab, the pressed enter. So I got ab at the next line. But I can't understand how it works. Before pressing enter the program doesn't read anything, right? After pressing, it reads a, save it to char c, then reads char c, writes a to the console. It's OK. But how can it read b being at the second line? It isn't b at the second line
cin is the standard input stream. The streaming nature is vital in-depth for understanding C++ I/O.
By default, doing cin >> x means:
From the point currently in the stream, skip any whitespace which might be there and then keep reading as long as possible & necessary to get a valid representation of x.
Let us disregard for a moment the fact that input comes from the keyboard. The content of the stream at start is a b LINEFEED. You execute cin >> c, which will read the first character, a, from input. That's enough to fill in c, so reading stops. The cin stream now contains b LINEFEED. The variable c is then written to standard output.
Another cin >> c comes next, so one more character is read (this time b). Again, one character is enough, so reading ends and the stream contents is just LINEFEED. The b is then sent to the standard output stream.
The fact that the standard input and standard output streams are normally tied to the console does not affect their internal working in any way. cin doesn't "forget" what was in it just because some output appeared on the screen in the meantime. In particular, cin reads the keyboard, not "characters on the console." It just so happens that pressing keys both echoes them on the console and feeds them to cin.
So the fact that your program has output the character a in the meantime has no effect on the contents of the cin stream.
cin is a blocked input. Whatever comes from the keyboard is stored in a buffer. When you press enter the system passes the buffer to the application code (std::cin code). Operator >> will decide how much to read from that buffer - one char, string, int, float etc. Depends on the type of the operand.
cin and cout are buffered streams. Both 'a' and 'b' goes into the input buffer when you press enter. The '>>' operator reads from that buffer (one char at a time in your case). The '<<' writes to the output buffer. The only thing that should surprise you is that you see "ab" on output without printing "\n" (the latter symbol should flush the contents of the output buffer to the terminal).In short, both cin and cout are buffers. Input and output operators work with those buffers. Newline symbol initiates the data transfer from real input to input buffer and from output buffer to the real output. There more thing about I/O you can learn.
Basically, cin has an overload for data type char to only grab 1 character from the input stream, so your program basically goes like this :
char c;
cin >> c; // reads 'a' from the input stream (input stream contains 'ab\n')
cout << c; // prints 'a'
cin >> c; // changes c to 'b' (reads 'b')
cout << c; // prints 'b'
Related
I am trying to implement a pause function in C++, but it is looping forever.
I am using macOS but I am trying to create a pause function that will work in any system... I believe my cin >> is not capturing '\n' or '\r' from the keyboard and it is looping forever.
void Transferencia::pause() {
char enter = 0;
while(enter != '\n' && enter != '\r') {
cout << "(Press Enter to Continue...) ";
cin >> enter;
}
cin.clear();
}
I want to pause my program until user press the key "enter".
But even when I press "enter/return" it keeps looping...
At very first: enter != '\n' || enter != '\r' is a tautology: Even if enter does equal one of the characters it cannot be equal to the other one. So one of the tests must be true... You actually want to stay in the loop when enter is unequal to both values.
std::cin >> ... won't read data before you press enter, but it will discard the newlines (actually, all whitespace). So it would suffice just to read one single character right without loop (the loop again would get an endless one); solely: If the user doesn't enter anything at all before pressing 'enter' key, there's no character to read from std::cin and we'd still be waiting.
What you can do is reading entire lines:
std::string s;
std::getline(std::cin, s);
That will accept empty lines as well, so does exactly what you want (note: no loop around!).
Edit (stolen from the comments; thanks, Thomas Matthews): An even more elegant way is
std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
as it won't create any additional resources that would be discarded afterwards anyway (the std::string object!).
Edit 2:
Depending on type of last input operation, there might still be a newline (or even further data) buffered, e. g. after int n; std::cin >> n;. In this case, you need to skip the input yet buffered. So you would need ignore twice.
However, if the last input operation consumed the newline already (e. g. std::getline – or if there wasn't any preceding input operation at all), then this would lead to user having to press enter twice. So you need to detect what's has been going on before.
std::cin.rdbuf().in_avail() allows you to detect how many characters are yet buffered. So you can have:
if(std::cin.rdbuf().in_avail())
{
std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
}
std::cout << "press enter" << std::endl;
std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
On some systems (including mine), though, in_avail can return 0 even though a newline is yet buffered! std::cin.sync_with_stdio(false); can fix the issue; you should execute it before very first input operation. Hopefully, you don't use C++ (streams) and C (scanf, printf, etc) IO intermixed then...
The easiest way to do this is with getline().
cin >> ignores whitespace, newline characters included. getline() will read an entire line, newline character included. However, it does not copy the newline character to the output string. If the user simply hit the enter key and nothing else, you'd end up with an empty string.
So, to get your desired behavior, you would construct your loop like this:
string line;
while(true)
{
cout << "(Press Enter to Continue...) " << endl;
getline(cin, line);
if(line == "")
break;
}
#Aconcagua has answered your question but this is what I want to add in.
Normally, for handling some specific kind of event in computer, we usually follow event-driven paradigm or event-callback.
The idea is there is an event loop that waits for a new event coming into the system. This case, keyboard is an event, the event loop then calls event-callback. What event-callback does is it compares the value of input with some conditions then do some other tasks (it might change some state of the program or notify users).
The idea is keep CPU busy by either 2 ways.
event-driven : do other tasks while waiting for a new event
multithreading: multiple threads in the system. This approach has the disadvantage is at data-race
Have fun
while(!(cin >> ar[i]))
{
cin.clear(); // clears bad input
while(cin.get() != '\n')
continue;
cout << "Invalid input, please enter valid scores";
}
The above code is from a much larger file. I copied this bit of a code from one of my textbooks and I don't really feel comfortable using it as I do not understand how this works.
I am using it as a measure to handle input errors.
So ar is an empty array of integers, if I decide to enter 'k', then
!(cin >> ar[i])
is true.
From here I clear the input buffer (I think that is correct, I'd like someone to confirm or dispute this please). The terminal then prints "Invalid input..."
Now if I just press Enter nothing happens, but isn't Enter the newline char? So shouldn't the code read
while(cin.get() == '\n'
?
while(!(cin >> ar[i]))
This tries to parse a value from cin and store it in ar[i]. By default, >> skips whitespace first, then sees if the characters in cin describe a legal value for whatever the type of ar[i] is. If a legal value is found, then cin stream state remains good, and its operator bool() const will kick in given the boolean not/! operation, such that the while loop will break.
If parsing fails though, the stream state will be set to one or more of:
bad (if there's some unrecoverable stream error, like stdin supplied over a network connection that gets disconnected),
fail (if the characters just didn't form a legal value for the type), or
eof (end of file, for a "proper" shutdown/close of the input, as supplied by ^D in UNIX/Linux, ^Z in Windows, and the end of input when a program's invoked as in echo input | program).
All the above modalities are described under "State Functions" here.
If the loop is entered due to any of the error conditions above...
{
cin.clear(); // clears bad input
...this does NOT clear any input data from the stream, but does clear the bad, eof and fail state flags, after which further input attempts can be made, though a stream that was in bad or eof state is likely to immediately reenter that state when further input is attempted (but not always - some OS may allow successful input after an eof conditions for std::cin if the user types/generates an EOF code then types actual text again...
while(cin.get() != '\n')
continue;
This tries to read characters from the terminal until a newline \n is encountered. The idea's clearly to clear out the rest of the presumed unparse-able input that might have led to a fail condition earlier. Sadly, if the problem was, or becomes, a bad or eof condition then this loop will hang the program, spinning burning CPU to no avail.
cout << "Invalid input, please enter valid scores";
}
If the problem was simply a mistyped value and no bad or eof condition, then the cout will prompt for further input.
Now if I just press enter nothing happens, but isnt enter the newline char?
Whenever the outer loop is executing cin >> ar[i] it will skip whitespace, including any extra newlines you type, until it sees some input (which may need to be a full newline-terminated line to get flushed by the terminal or program feeding it to the program), or a bad or eof condition. The inner while-loop is not there to get rid of empty lines - it's trying to discard the line with presumed non-numeric text in it.
Corrected code:
while (!(std::cin >> ar[i]))
{
if (std::cin.bad() || std::cin.eof())
{
std::cerr << "Fatal error on cin while reading numbers\n";
exit(EXIT_FAILURE);
}
std::cin.clear();
std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
std::cout << "Invalid input, please enter valid scores\n: ";
}
The goal of this entire code is to keep printing errors and requesting input until the user enters a valid number before continue further into the program.
The loop that the entire code is enclosed in...
while(!(cin >> ar[i]))
says to loop if the input in the cin stream is invalid. Since ar is an array of integers, the input would be invalid if it is not a number.
cin.clear(); // clears bad input
When the cin stream encounters invalid input, the program begins executing the loop and continues to this line of code. Since the stream encountered invalid input, it has a flag that says there is an error. This requires that you, as the comment puts it, "clear bad input." Basically what this does is get rid of this flag. If this is not done, the flag will remain in the stream and the program will encounter another error next time the cin stream is used, regardless of whether or not the user input is valid.
while(cin.get() != '\n')
continue;
When the program took the input from the user, it took the string, char, whatever was the invalid input, but left the '\n' in the cin stream. To prevent errors the next time the cin stream is used, the program must get rid of that '\n', along with anything else that was lefty behind. cin.get() reads only one char from the cin input stream and returns it. Since the return value of this function is not being assigned to anything, all this does is discard the char that was read. In the case that more than the '\n' was left behind in the stream, this loop checks the value of the read char before disposing of it. This way, the loop keeps executing while the char that is read is NOT '\n'. Or in other words, it loops until the char that is read IS '\n'. The only thing that continue does, is tell the program to skip the rest of the current iteration of the loop and start the next iteration. In this situation, this is equivalent to giving the loop an empty body. You could very well replace continue; with {} and the program would do the exact same thing.
cout << "Invalid input, please enter valid scores";
The program has cleared the flag in cin and has also cleared any data from cin that may have been left behind. Now that all the errors from the invalid input have been handled, there is only one more thing to do. It's time to notify he user that the input was invalid and request new input. If the user enters more invalid input, the loop repeats. If the user enters valid input, the program continues on to the next line of code.
I recently wrote a program that takes inputted char data, tests if it is acceptable (a-z, # marks the end of the input) and puts it in a stack which then tests to see if it's a palindrome. I was expecting to enter it one char by a time, but if I enter a string ended by pound it.. works. Here is some of the relevant code:
char buffer;
bool pound_test = false;
bool palindrome = false;
bool keep_going = true;
stack<char> stack1, stack2, stack3;
string str = "";
cout << "Please enter a string, then end it with the pound sign. " << endl;
while(pound_test == false) {
cin >> buffer;
if((buffer >= 97) && (buffer <= 122))
{
stack1.push(buffer);
stack2.push(buffer);
str += buffer;
}
if((buffer >= 65) && (buffer <= 90)) {
buffer = buffer + 32;
stack1.push(buffer);
stack2.push(buffer);
str += buffer;
}
if(buffer == '#')
pound_test = true;
}
So, when the user enters one long string, like "racecar#" and presses enter, the program properly puts it into the stack. My question is simply: why? Wouldn't the data have to be inputted one char at a time for it to work properly, because the cin is in the loop itself, and the loop has to repeat to enter multiple chars into the stack, right? Thanks!
Edit: Thanks for the answers/comments everyone! I'm really impressed by the quick and kind replies. I'm certainty going to use this site again.
Console input (via the cin std::istream object) in most systems is line buffered. So when you call cin::operator>> for a single character, the function does not in fact return until you press newline (because the underlying I/O system does not make data available to cin until then). Any data entered up-to and including the <newline> will be buffered and subsequent calls to cin::operator>> will be serviced from the buffer until it is exhausted.
In this case cin >> buffer, where buffer is of type char will indeed get a single character, but before that the console buffered an entire line and will use it to satisfy subsequent console input operations.
If you step through your code in your debugger the operation may be clearer to you.
The "system" (OS, library, whatever — depends on the implementation) ate the string of data coming from input, but your program read it char by char.
While all the answers about os buffering are true, I think the confusion can be traced to cin's operator >> (char); because C++ can overload methods based on their argument types, the char version of operator >> is only assigning one character at a time, even though the whole string is buffered. I believe you're thinking that operator >> should try to put the whole string into your character; but since it "knows" you're reading one character at a time, it only assigns one character at a time. I'm not sure if this is specified behavior for cin or not, but that seems to be what's happening.
The cin operator reads from the standard input stream (if not configured otherwise). The stdin works as follows: you type and when you press Enter, it is sent to stdin and therefore cin reads the whole string up to the moment when you pressed Enter.
If you wish to read char by char, you should use getchar.
The way your keyboard input is seen by cin >> buffer;is not a property of your program, but of the combination of OS, Shell, C runtime and maybe thousand things I forgot.
My problem is, that I want to read the input from std::cin but don't know how long the input is. Also I have to char and can't use std::string.
There are two ways I have to handle:
a) The user inputs text and when he hits [ENTER] the program stops reading.
b) The user redirects std::cin to a file (like .\a.oput < file) which can hold multiple lines.
Edit: Just noticed that std::cin.eof() is always false also in the case of reading form a file.
For a) I could read until \n occures. For b) Edit: No (I could read until std::cin.eof() occures.)
But when I don't know whether I'm getting an a) or a b) problem, how can I break the reading process?
This is what I have for a) ...
char buffer = ' ';
while(std::cin >> std::noskipws >> buffer && buffer != '\n')
{
// do some stuff with buffer
}
... and b)
char buffer = ' ';
while(std::cin >> std::noskipws >> buffer)
{
// do some stuff with buffer
}
Also I know there is std::cin.tellg() to get the current position in the stream.
Edit: So it seems like in case of the file the input streams gets terminated, in the way that std::cin >> std::noskipws >> buffer gets false.
What the code above does for a):
It waits for the user to make an input and press [ENTER]
Then it loops through every char entered by the user on the last line.
Then it waits again for the user to make an input and press [ENTER]
Infinite-waiting-processing-loop
So how do I do it?
You could require the input to always end EOF (meaning from commmand line requiring ^D to be pressed) and then use the process for b as always. This would then enable multiline input from cmdline as well
You could use the (old) getline function, which takes a pointer to a char array and can use a delimiter. But you wont be able to ensure that in every case it will read to the eof (as the char buffer might be too small), but using a char-array and not paying attention to the size of it is a very dangerous (and from the point of security catastrophic) thing anyways as it can lead to buffer-overflows which can be easily exploited.
This code should enable you to extract line by line from the input:
char buffer[256];
while(getline(buffer,256,'\n')) { //get a line
/* do something with the line */
}
This to read a maximum amount of chars:
char buffer[256];
while(getline(buffer,256)) {//get a maximum amount out of the input
/* do something with the line */
}
Does anyone knows why C instruction is being reordered when cin cout and gets is used consecutively here?
I am using Dev-C++ 4.9.9.2.
#include<iostream>
using namespace std;
int main(){
char a[10],b;
for(;;){
cout<<"\ncin>>b:";
cin>>b;
cout<<"gets(a):";
gets(a);
cout<<"cout<<a<<b:"<<a<<" "<<b<<"\n\n";
}
}
I got an output like:
cin>>b:132
gets(a):cout<<a<<b:32 1
cin>>b:465
gets(a):cout<<a<<b:65 4
cin>>b:312242
gets(a):cout<<a<<b:12242 3
cin>>b:1
gets(a):cout<<a<<b: 1
cin>>b:
It seemed like some input for cin was passed in gets.. and it also appears that instructions were reordered like:
cin>>b;
gets(a);
cout<<"gets(a):";
instead of,
cin>>b;
cout<<"gets(a):";
gets(a);
cin>>b read just a character, leaving the rest of the input to be read by later input operation. So gets sill has something to read and don't block.
At the first cin >> b, there is no input available. You enter '132\n' (input from terminal is usually made line by line) in a buffer and just get the 1 out of it. gets reads the next characters 32 and the \n which terminates gets. It doesn't need to read something more from the terminal.
Nothing has been re-ordered.
your input from keyboard has been send only when you pressed enter. At that time, there have been enough data to execute the cin<<b, the following cout, then to complete the gets(a).
In others words, the execution of cin<<b is suspended to the reception of a char. But that char is not send to the program until you pressed 'Enter' (this is because of your terminal settings). When you press 'Enter', the first char is received by cin<<b and the remaining is buffered. cout executes, and when it is the turn of gets(a), the buffer delivers the remaining chars included the carriage return, so gets(a) completes as well, with the data you entered to complete the cin<<b instruction.
Try to simply press enter for the cin<<b to complete, then you'll see the cout, and then you will have the gets(a) waiting for your inputs.
While not really answering your question...
The idiomatic way in C++ would rather be to use getline. It's an accident of history that does not make it part of the iostream interface directly, but it really is the function to use for inputs.
Shameless plug from the website:
// getline with strings
#include <iostream>
#include <string>
int main () {
std::string str;
std::cout << "Please enter full name: ";
getline (std::cin,str);
std::cout << "Thank you, " << str << ".\n";
}
The main advantage of getline, in this version, is that it reads up until it encounters a line-ending character.
You can specify your own set of "line-ending" characters in the overload accepting a third parameter, to make it stop on commas or colons, for example.
The code isn't reordered, but std::cout is buffered so the string doesn't appear immediately on your display. Therefore gets(a) will be executed with the output still in the buffer.
You can add a <<flush after the output string to make cout flush it's buffer.
When you use std::cin, it knows how to tell std::cout to flush the buffer before the input starts, so you don't have to.