High quality C++/C Programming Guide-11th chapter-Other programming Experience (2)

11.1.3 Const member function

Any function that does not modify the data member should be declared as a const type. If you accidentally modify a data member while writing a const member function, or call another non-const member function, the compiler will point out the error, which will undoubtedly improve the robustness of the program.

In the following program, the member function GetCount of the class stack is used only for counting, and logically getcount should be a const function. The compiler will indicate an error in the GetCount function.

Class Stack

{

Public

void Push (int elem);

int Pop (void);

int GetCount (void) const; Const member function

Private

int m_num;

int m_data[100];

};

int Stack::getcount (void) const

{
+ + M_num; Compilation error, attempting to modify data member M_num

Pop (); Compilation error, attempt to invoke non-const function

return m_num;

}

The declaration of a const member function looks strange: The const keyword can only be placed at the end of a function declaration, presumably because other places are already occupied.

11.2 Improve the efficiency of the program
The time efficiency of the program refers to the running speed, and the space efficiency is the condition of the program consuming memory or external storage.

Global efficiency refers to the efficiency that is considered in the view of the whole system, and the local efficiency is the efficiency which is considered from the point of view of module or function.

L "rule 11-2-1" do not blindly pursue the efficiency of the program, should be satisfied with the correctness, reliability, robustness, readability and other quality factors, try to improve the efficiency of the program.

L "rule 11-2-2" to improve the overall efficiency of the program, and improve the local efficiency as a supplement.

L "Rule 11-2-3" in optimizing the efficiency of a program, you should first identify the "bottleneck" of efficiency, and don't optimize it in a trivial place.

L "Rule 11-2-4" first optimizes the data structure and algorithm, then optimizes the execution code.

L "Rule 11-2-5" Sometimes the time efficiency and the space efficiency may be opposite, at this time should analyze that more important, make the appropriate compromise. For example, spend some extra memory to improve performance.

L "rule 11-2-6" do not pursue compact code, because compact code does not produce efficient machine code.

11.3 Some useful suggestions
2 "recommendation 11-3-1" Beware of those visually difficult to distinguish the operator to write errors.

We often mistakenly write "= =" as "=", such as "| |", "&&", "<=", ">=" such symbols are also prone to "lose 1" error. However, the compiler does not necessarily automatically indicate such errors.

2 "recommendation 11-3-2" variables (pointers, arrays) should be initialized as soon as they are created to prevent the uninitialized variables from being used as right values.

2 "recommendation 11-3-3" Beware of the initial value of the variable, the default error, or insufficient precision.

2 "recommendation 11-3-4" Beware of errors in data type conversions. Try to use explicit data type conversions (let people know what's happening) and avoid the compiler's implicit data type conversions.

2 "recommendation 11-3-5" Beware of the overflow or underflow of variables, and the subscript of the array is out of bounds.

2 "recommendation 11-3-6" Beware of writing an error handler, beware of error handlers themselves.

2 "recommendation 11-3-7" Beware of file I/O errors.

2 "recommendation 11-3-8" Avoid writing highly skilled code.

2 "recommendation 11-3-9" Do not design an exhaustive, very flexible data structure.

2 "recommendation 11-3-10" If the original code quality is better, try to reuse it. But don't fix bad code, you should rewrite it.

2 "recommendation 11-3-11" Try to use the standard library functions, do not "invent" the existing library functions.

2 "recommendation 11-3-12" Try not to use variables that are closely related to specific hardware or software environments.

2 "recommendation 11-3-13" Sets the compiler's selection to the strictest state.

2 "recommendation 11-3-14" Use tools such as Pc-lint, Logiscope, if possible, for code review.

Reference documents
[Cline] Marshall P. Cline and Greg A. Lomow, C + + FAQs, Addison-wesley, 1995

[Eckel] Bruce Eckel, thinking in C + + (C + + programming ideas, Liu Zongtian, etc.), machinery Industry Press, 2000

[Maguire] Steve Maguire, writing clean Code (programming essence, Jiang JINGPO, etc.), Electronics publishing House, 1993

[Meyers] Scott Meyers, effective C + +, Addison-wesley, 1992

[Murry] Robert B. Murry, C + + strategies and Tactics, Addison-wesley, 1993

[Summit] Steve Summit, C programming FAQs, Addison-wesley, 1996