First, declare, such a title, the purpose is to "sensational" and attract readers. :) The defects of the two functions in the text are not what I found, but I think it is very meaningful, sharing with you. Moreover, you can understand the "defect" of a mature system, isn't it very pleasant and excited?
Some of this article quoted Lin Rui's "High Quality C / C Programming Guide". (I suggest everyone to read, especially when I find a job, many small companies use the C test questions in the book as a written question :))
1: Printf ()
I believe everyone has used it, and the TRACE in the MFC has the same problem. PRINTF () defects are unsafe and inelatable.
1) About unsafeness, the "High Quality C / C Programming Guide" has a clear explanation:
[Recommendation 6-1-2] Try not to use the type and number of uncertain parameters.
C Standard Library Function Printf is a typical representative using uncertain parameters, its prototype:
INT Printf (const chat * format [, argument] ...);
This style of function has lost strict type safety inspections at compile.
INT I;
Printf ("% s", i); // cannot use a strict type security check when compiling.
2) Regarding inelability, it means that it cannot be used with custom types. Please see the following code:
INT I;
Float f;
Cstudent Student; // Customized type, which is overloaded << operator
Cout << i << f << student;
Printf ("% D% f", i, f); // cannot be used with Student
2. GetChar () function, "High Quality C / C Programming Guide" has a clear explanation
1) [Rule 6-2-2] Function Name and return value type in semantic conflict.
A typical representative of this rule is a C standard library function getchar.
E.g:
Char C;
C = getchar ();
IF (c == EOF)
...
According to the GetChar name, the variable C is declared as a CHAR type is a natural thing. But unfortunately, getChar is indeed not a char type, but the int type, its prototype is as follows:
INT getchar (void);
Since C is a char type, the value range is [-128, 127], if the value of the macro EOF is outside the value of char, then the IF statement will always fail, this "danger" people generally get it! The responsibility of this error is not in the user, is the function getchar misleading the user.
2) [Rule 6-2-3] Do not return the normal and error flags together. Normal values are obtained with output parameters, and the error flag returns with the return statement.
Review the above example, why do the designers of the C standard library function be declared as a confused int type? Will he be so stupid?
Under normal circumstances, getChar does return to a single character. But if getchar hits the file end flag or a read error, it must return a flag EOF. To distinguish between normal characters, you have to define EOF as a negative number (usually negative 1). Therefore, the function getchar is an int type.
In actual work, we often encounter the above problems. In order to avoid misunderstandings, we should separate the normal values and error signs. That is, the normal value is obtained with the output parameters, and the error flag returns with the return statement.
The function getchar can be rewritten into BOOL getchar (char * c); although GeChar is flexible than getchar, such as Putchar ()); but if getchar is wrong, what is its flexibility?
