EOF
EOF (end of file) is a status returned by the file read operation. It is not a value read from the file, instead, it is a return value when the file reading function reads the end Of the file or cannot read down. The returned value is generally-1, which is also the value defined for the EOF macro in most systems. Because of this special return value, the return values of functions such as getch () and getchar () are int rather than char, which will be discussed later. EOF can be detected by the return value, EOF () or feof () function. On the Windows console interface, you can
CTRL + Z to simulate the end of the file. \ R \ n refers to the line feed. The line feed refers to moving the cursor (or file position pointer) to the line header, and the line feed refers to moving the cursor to the next line. The end of a row has a different representation in different systems. On the Internet, there is a description of their origins and differences: before the computer appears, there is a kind of device called teletype model 33, which can contain 10 characters per second. But there is a problem, that is, when a line breaks a line, it takes 0.2 seconds, just two characters. If a new character is passed in the 0.2 s, the character will be lost.
As a result, the developers thought of a way to solve this problem, that is, adding two end characters after each line. One is "enter", which tells the typewriter to position the print head on the left boundary, and the other is "line feed", which tells the typewriter to move the paper down one line.
This is the source of "line feed" and "Carriage Return". They can also be seen in their English names.
Later, computers were invented, and these two concepts were invented on computers. At that time, memory was very expensive. Some scientists thought it would be too waste to add two characters at the end of each line. Just add one character. As a result, there were differences.
In Unix systems, each line ends with "<line feed>", that is, "\ n". In Windows systems, each line ends with "<press enter> <line feed> ", that is, "\ r \ n". In MAC systems, the end of each line is "<press enter> ". One direct consequence is that if a file in UNIX/MAC is opened in windows, all the text will be changed to a line; if a file in Windows is opened in UNIX/MAC, A ^ m symbol may be added at the end of each line.
In order to unify the differences, the C language specifies that the end of the file line is a line break, that is, '\ n', which is why we use printf ("\ n"); To achieve carriage return + line feed. In addition to Unix (UNIX itself uses '\ n' to indicate the end of the row), for example, in windows, when the C language reads a file, if "\ r \ n" is read, the carriage return '\ R' is discarded and only' \ n' is used to indicate that the row ends. Here, reading refers to reading a text file. If reading a file in binary format, this processing is not performed (the C language ensures binary transparency ). The fopen function parameters include "R" (opened as a text file for reading) and "rb" (opened as a binary file for reading. In Unix systems, "R" and "rb"
There is no difference, that is, transparent transmission. Of course, the C language also performs corresponding processing ("\ n"-> "\ r \ n") when writing text files "). After getchar () and getch () understand the two important concepts above, we will select the two character reading functions in C for analysis: getchar () We are familiar with it, it reads a character from the stream pointed to by stdin (usually called the console) and returns the character. If the stream pointed to by stdin is at the end of the file, it returns-1. As mentioned above, because of the special values of EOF, the returned value of getchar is int rather than char, which may cause a lot of trouble due to implicit conversion of C. For example, char C; while (C = getchar ())! = EOF) putchar (c); at first glance, the program can exit when getchar returns-1, because C is signed Char, it is 0xff after the truncation of the int type-1 (32 1) is received. In C = EOF, C is implicitly converted to the int type because C is signed, therefore, the extended bits return to 0 xffffffff, So C is still equal to-1. However, this is a risk. When the character 0xff obtained by getchar returns 0x000000ff, the returned value is converted to Char to get 0xff, which is equal to-1, that is, eof, which causes the loop to exit early. Apparently it is not the program's intention. You may want to define C as unsiged Char to avoid 0xff =-1, for example, unsigned char C; while (C = getchar ())! = EOF) putchar (c); this causes another risk: When getchar () returns-1, it is converted to unsiged char 0xff, that is, 255. when C and eof are compared, it is converted to int. Because C is unsigned, (INT) C is 0x000000ff, that is, it is still 255. therefore, the loop will never exit, because unsiged Char will never get-1. after discussing this, let's take a look at the correct usage: int C; while (C = getchar ())! = EOF) putchar (c); here we only consider how to distinguish between the character 0xff and the returned value EOF (0 xffffffff ). When the character 0xff is read, getchar returns 0x000000ff C and receives 0x000000000000ff, which is obviously not equal to-1. When C is converted to Char, it can get 0xff correctly. When EOF is returned, getchar returns 0 xffffffff, which causes C encoding to be 0 xffffffff =-1 and exit cyclically. Getchar () is also confusing for beginners: Sometimes we only want to read one character from the console, but after entering one character, getchar () does not return immediately, for example, the above Code does not output putchar (c) immediately after we input a character. But when we input ABC and press enter, the program will immediately output ABC and wrap it. This is because, as mentioned above, getchar () returns the next character of the stream to which stdin points. This stream has a buffer. When you press enter, the input data (including carriage return and line feed) will be input) in the stream buffer (one of the explanations for this input method is that when there were no terminals (that is, the console we called) long ago, Data Reading was performed through files, all files end with rows. Therefore, to improve Io efficiency, data is sent to the stream buffer only when a row is changed .) In this way, getchar () extracts characters from the stream buffer, so ABC and line feed seem to be printed at one time, which is actually read and printed one by one. Next let's take a look at the three differences between getch () and getchar (): 1. getch () does not read data from the buffer of the stream pointed to by stdin, but directly reads data from the keyboard input. This means that when you input ABC, each input character, getch () this character is returned. 2. getch () does not display the characters, that is, the characters you entered are not displayed on the console. This allows us to interrupt the waiting for user input in the console program through getch (). For example, when all console programs end, there will be a press anykey to continue .. this is through: puts ("Press anykey to continue .. "); getch. In this way, the user input can respond in a timely manner, without entering the carriage return (difference 1) every time, and because the input is not displayed, it does not affect the aesthetics of the program. You may have tried to click the EXE file under the debug file of the console program. The console is always transient, because in the EXE file generated on the console, there is no getch () automatically added by the system (). 3. getch is included in the conio. h header file. It can also be seen that it is not strictly c Standard io (for example, getchar () is located in the stdio. h header file ). We can select one of these two types in the actual program to implement the corresponding function. When getting a character through getchar, we often have such negligence. after entering a letter and pressing enter, getchar gets the value of this character, but forgets to process the rest of the carriage return in the stream buffer. In this case, we can use getch () and add echo. the following is an interesting small program about them # include <stdio. h> # include <stdio. h> void main () # include <conio. h> {void main () int c = getchar (); {printf ("% d", c); int c = getch ();} printf ("% d ", c);} The former outputs 10, that is, '\ n', and the latter outputs 13, that is,' \ R'. I read a lot of information on the Internet, which is vague and unclear. I am not very clear on my own, according to my own understanding. When the Enter key is pressed, the system will receive '\ R'. However, the system will explain the carriage return differently due to different environments (such as text editing environments. In a text editing environment (such as Notepad, word, and console ), the carriage return is interpreted by windows as "\ r \ n", that is, the carriage return is a line break (because "\ r \ n" in Windows indicates the end of the line ). In this way, the output of the second program can be interpreted. As getch () captures input from the keyboard, it gets '\ R' (I have also considered the possibility of getch () "\ r \ n" will also be obtained, but if you add a sentence C after printf
= Getch () and output. Instead of getting two outputs 13 10, you can only get 13 ). When you press ENTER for a line break and place it in the buffer of the C Io stream, you must comply with the C Specification, that is, the end of the line is represented by a line break, that is, "\ r \ n" and interpreted as '\ n '. As mentioned above, we can abstract the console into a file. In fact, C also uses stdin stdout stderr as the file descriptor (0, 1, 2 in UNIX) provided to developers. When reading the data in the console, that is, reading the file, we need to modify the end of the row of Windows itself. Therefore, getchar () gets '\ n '. The previous statement is completely unfounded and far-fetched. I guess only, and hope to understand this expert's message correction. The key to C language I/O is EOF, stream buffering, relocation, and how to unify the file representation in different environments.
