# include & lt; Cstdlib> 
#include  
using namespace std; 
Int main () 
{
Int num=0; 
int count=0; 
Char ans [90] [90]. 
//while the scanf (" % s ", ans [num])!=(EOF) 
While (cin> Ans [num]) 
{
Cout & lt; <"Enter the ans [" & lt; & lt; num & lt; & lt;"] ". 
num++; 
} 
Cout & lt; For (int I=0; I & lt; Num. I++) 
{
Cout & lt; <"Ans [& lt; & lt;" I & lt; & lt; "] : "& lt; } 
return 0; 
} 

Environment: win10 + GCC 8.1.0
Through the terminal receives a, separated by a space character string from an array of small programs, meet EOF is stop accepting string
Here intentionally in the end into the CTRL + z, CTRL + z at this time should not be identified as the EOF, read it stopped immediately and request a new input
When using are commented out "in the application of the scanf EOF will exit the loop while, behavior is as follows:



Here when requesting a new input, input CTRL + z again, this time still not quit a while, but just reside CTRL + z (at this point it's in the stdin into the original ASCII 26 CTRL + z, rather than the EOF) read into the array
Then ignore the second input CTRL + z, again, while requesting a new input,
Note that the second input CTRL + z tends to disappear, for the first time in the end the CTRL + z somehow also leave a little bit of "trace", left a ASCII 26, the second type CTRL + z met, in turn, returns EOF, neither let the scanf direct again not leave "trace",

Then read a second time after the end CTRL + z request input, do not enter CTRL + z?
1. If the enter directly: effect and input the CTRL + z, that is described above and the effect of the type CTRL + z didn't knock and enter the same directly, if CTRL + z never happened,

2. If the input string: other CTRL + z's original ASCII stick in the front of the the string, and then deposited in the array


At the end of all these actions above, a new line, direct input CTRL + z, the scanf finally identified the CTRL + z, while over,

Without using the scanf and cin?

If in the input string, other behavior like the above 2, ASCII 26 stick in front and with the string into an array
If direct input CTRL + z, directly recognized as the EOF, and the CTRL + z of ASCII 26 is deposited in the array, while the end,

Find a lot of related problems, such as input CTRL + z is over twice, such as EOF related problems
Interpretation of cin behavior is good (own), CTRL + z is in front of the other content was not accepted for EOF, only as a symbol of an input end and to the natural shape of "ASCII 26" appear in the stdin, internal pointer refers to the normal content of normal operation to the front, and a pointer to it to stop, no follow-up action, to request a new input,
Pointer pointing to still wasn't new input came in dealing with the CTRL + z (ASCII) 26, with a carriage return, it is also as other content is read into the "late",
If new input is CTRL + z, as normal, "a new line" CTRL + z is identified as trigger returns EOF conditions, this is also why no two "ASCII 26",

But not good when using the scanf explained, which is where the CTRL + z? Neither trigger returns EOF, and not as ASCII into the array,
There may be friends will think of, a string of a string with CTRL + z, CTRL + z content will not be read, still reside buffer,
So if that's the case, then the CTRL + z also won't disappear, and if so, cin and the scanf behavior is not the same,
Or more claims about this mechanism?

Another kind of people can think of the problem is that while in cin, there is some difference in the scanf judgment condition, problem in this difference,
After the second CTRL + z input, the scanf read in ASCII 26 reside, the return value is 1 (read the success one data), satisfy conditions 1!=EOF, and then left in the loop, CTRL + z is due to some reason ignored,
While & gt;> For some reason, not only read of the 26 reside, also identify the CTRL + z,
The "probable cause" if so, what is it? My intuition told me may be different from C and C + + flow, it is really so? Or simply other what reason?
The younger brother stupid, please feel free to comment

CodePudding user response:

Is too long. Can you describe the simple,,,

CodePudding user response:

Linux:

Windows:
, ,

CodePudding user response:

references to Tiger - 1/3 d response:

is too long. Can you describe the simple,,,

Is a little thin, simple description easier to describe not clear
Really simple said:
When entering a string of a string, the end of the string is CTRL + z (CTRL + z) for the first time, to the scanf receive and note that this certainly cannot be identified as EOF CTRL + z, this is obviously,
Press enter after the application request new input, press CTRL + z once again the second time (CTRL + z) and press enter, still unable to identify the CTRL + z to EOF, program and just continue to leave just now on the end of the CTRL + z ASCII read into the array,
Even if this time does not press CTRL + z, just press enter, a program to do the same thing, as if CTRL + z (second) have not seen,

Only after the return, once again enter CTRL + z (CTRL + z) for the second time, then can let the scanf returns EOF,

And if receive cin with a string of a string, the end of the string is CTRL + z (first), press enter, then CTRL + z at the end of the content of the former are normally read, then request the new terminal input,
The difference is that now once again enter CTRL + z (second), the CTRL + z can be identified as EOF immediately, and just stay at the end of the sentence reads ASCII is normal of CTRL + z (note that this is two different CTRL + z), don't need to CTRL + z appear for the third time,

CodePudding user response:

Correct one word

reference qq_36360603 reply: 3/f

Quote: reference to Tiger - 1/3 d response:

is too long. Can you describe the simple,,,

Is a little thin, simple description easier to describe not clear
Really simple said:
When entering a string of a string, the end of the string is CTRL + z (CTRL + z) for the first time, to the scanf receive and note that this certainly cannot be identified as EOF CTRL + z, this is obviously,
Press enter after the application request new input, press CTRL + z once again the second time (CTRL + z) and press enter, still unable to identify the CTRL + z to EOF, program and just continue to leave just now on the end of the CTRL + z ASCII read into the array,
Even if this time does not press CTRL + z, just press enter, a program to do the same thing, as if CTRL + z (second) have not seen,

Only after the return, once again enter CTRL + z ( 3 CTRL + z), then can let the scanf returns EOF,

And if receive cin with a string of a string, the end of the string is CTRL + z (first), press enter, then CTRL + z at the end of the content of the former are normally read, then request the new terminal input,
The difference is that now once again enter CTRL + z (second), the CTRL + z can be identified as EOF immediately, and just stay at the end of the sentence reads ASCII is normal of CTRL + z (note that this is two different CTRL + z), don't need to CTRL + z appear for the third time,

CodePudding user response:

I tried, didn't appear the phenomenon of the building Lord said,

CodePudding user response:

reference 5 floor QZJHJXJ reply:

I tried, didn't appear the phenomenon of the original poster said,

What is the Pal compiler?
Am I a compiler bug or other environmental problems?

CodePudding user response:

Win10 + c + + builder

CodePudding user response:

The

reference 7 floor QZJHJXJ response:

win10 + c + + builder

nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull