While (CIN> S) Exit

Today, I saw a post on csdn, which reminds me of the while (CIN> S) exit problem.

ProgramAs follows:

# Include <iostream>
# Include < String >
# Include <vector>
# Include <algorithm>
# Include <functional>
 Using   Namespace STD;

 Int Main ()
{
Vector < String > STR;
 String S;
 While (CIN> S)
Str. push_back (s );
 For (Vector < String >:: Iterator it = Str. Begin (); it! = Str. End (); ++ it)
Cout <* It < "  " <Endl;
Sort (Str. Begin (), str. End ());
 For (Vector < String >:: Iterator it1 = Str. Begin (); it1! = Str. End (); ++ it1)
Cout <* it1 < "  " <Endl;

 Return   0 ;
}

Of course, csdn has such a post, but it only gives the answer and does not give a reason.

In Windows, press Ctrl + Z to exit.

In VC ++ 6.0 Console mode, CTRL + z displays ^ Z. Of course, ^ Z simulates the end of the file (EOF) in VC ).

However, I enter Ctrl + z after entering some characters. This loop does not exit immediately, but I need to enter Ctrl + z twice.

 

The cause has been analyzed by a cool man.

As follows:

The input buffer is a row buffer. After entering a string of characters on the keyboard and pressing enter, these characters are first sent to the input buffer for storage. Every time you press the Enter key, Cin. Get () checks whether readable data exists in the input buffer. Cin. get () also checks whether there are Ctrl + Z or Ctrl + D keys on the keyboard as the stream stop sign. There are two ways to check the result: blocking and non-blocking.

Blocking Check means that the CTRL + z combination key is used only after the Enter key is pressed, the non-blocking mode refers to the method of responding immediately after pressing CTRL + D. If you have entered characters from the keyboard before pressing CTRL + D, CTRL + D serves as a carriage return, that is, sending these characters to the input buffer for reading, in this case, CTRL + d no longer serves as the stream Terminator. If you do not have any keyboard input before pressing CTRL + D, CTRL + D indicates the end of the stream.

In Windows, blocking-type ctrl + Z and non-blocking-type ctrl + D are usually used in Unix/Linux systems. I am in windows, so I use the blocked Ctrl + Z to mark the end of the stream.

This blocking method has one feature: it is possible to detect whether Ctrl + Z is pressed before pressing the carriage return. Another feature is that if there is readable data in the input buffer, CTRL + Z will not be detected (because there is data to be read, it cannot be considered at the end of the stream ). Another thing we need to know: Ctrl + z does not produce a common ASCII code value, that is, it does not produce a character, therefore, it is not stored in the input buffer as other characters entered from the keyboard. After understanding these points, you can explain the questions raised by the landlord.

After entering ABCD ^ Z on the keyboard and pressing enter, it will be handled in the Windows system as follows: Due to the press ENTER function, the previous ABCD and other characters will be sent to the input buffer (Note: As mentioned above, ^ Z does not generate characters, so it is not stored in the input buffer, and there is no ^ Z in the buffer ). In this case, Cin. Get () detects that data already exists in the input buffer (so it no longer checks whether ^ Z input exists), and reads the corresponding data from the buffer. If all the data is read, the input buffer is empty again, and CIN. Get () waits for the new input. It can be seen that even if ^ Z is pressed, the stream will not end because there are other input characters (ABCD) before this.

Therefore, the input stream end condition is: ^ Z cannot have any character input (except press Enter), otherwise ^ Z cannot end the stream.

> If you enter ABCD ^ zabcd
> Program echo ABCD
> And wait for the input, that is, the result after ^ Z is no longer displayed.
> Why is it not handled?

In this case, ^ Z can be understood as the termination of the keyboard input, but not the termination of the stream.

Refer:

(1) http://blog.csdn.net/ming6/article/details/106271 (Reason Analysis)

(2) http://topic.csdn.net/t/20060616/09/4824782.html