C/C ++ programming novice error quotations

1. Introduction
I still remember that I had a trick in mathematics and English, that is to make a wrong question set. Review this incorrect question set frequently to avoid making the same mistake next time. Almost all programmers start from making mistakes. It is also necessary to summarize the Common Errors of new programmers. This article aims at this. All listed in this article are the real voices of new users I have come into contact with in project development. I have studied the Cultural Revolution and called it "Incorrect quotations ".

2. Quotations
(1) "My programs are all right. Can I leave it alone? BR> think about your surroundings, do some people also say this? If you have said this before, stop it. Don't say this again, because it only shows the ignorance of the speaker. Since the program is correct, why is the result incorrect?

(2) "program = Algorithm + Data Structure"
If we have just finished the C language, we can fully understand it and it can be said that it is correct. However, if you are a programmer who is about to engage in C/C ++ programming, it is a pity that this statement can only be judged wrong. However, there is another saying in the world:
Program = Object + message
"Program = Algorithm + Data Structure" is only applicable to process-oriented languages (c), while for object-oriented languages (C ++ ), it can only be expressed as "program = Object + message ". Traditional procedural programming languages are process-centric and algorithm-driven, while object-oriented programming languages are object-centric and message-driven. The message here is in a broad sense. Object A calls the member function of object B and can be seen as object a sending messages to object B.

(3) "compile the program and run it correctly"
Running a proper program is not necessarily a good program. The programmer must keep in mind that the program he or she writes is not only visible to himself, but also easy for others to understand. Unfortunately, many new programmers cannot clearly control the structure of the software. The concepts of the opposite file and implementation file are vague, and the written program is poorly readable.

C Programs adopt Modular programming ideas. A large software should be reasonably divided into a series of functional independent parts to complete the system's requirements. The module division is mainly based on functions. The module consists of the header file and the implementation file. The correct method for using the first object and the implementation file is:
Rule 1 header file (. h) is the declaration of the interface of this module. The interface includes the external functions and external global variables provided by this module to other modules. in H, the object is declared with the extern keyword;
The functions and global variables in Rule 2 must be declared with the static keyword at the beginning of the. c file;
Rule 3 never defines variables in. H files;

Many programmers are not clear about defining variables and declaring variables. The difference between defining variables and declaring variables lies in defining Memory Allocation Operations, which is the concept of the compilation phase; the declaration only tells the module that contains the Declaration to find external functions and variables from other modules during the connection phase. For example:

/* Module 1 header file: module1.h */
Int A = 5;/* define int A */In the. h file of Module 1 */
/* Module 1 implementation file: module1. C */
# Include "module1.h"/* contains the. h file of Module 1 in Module 1 */
/* Module 2 implementation file: module2.c */
# Include "module1.h"/* contains the. h file of Module 1 in Module 2 */
/* Module 2 implementation file: module3. C */
# Include "module1.h"/* contains the. h file of Module 1 in Module 3 */
The result of the above program is that the integer variable A is defined in Modules 1, 2, and 3. A corresponds to different address units in different modules, which obviously does not conform to the author's intention. The correct method is:
/* Module 1 header file: module1.h */
Extern int A;/* declare int A */In the. h file of Module 1 */
/* Module 1 implementation file: module1. C */
# Include "module1.h"/* contains the. h file of Module 1 in Module 1 */
Int A = 5;/* define int A */In the. c file of Module 1 */
/* Module 2 implementation file: module2. C */
# Include "module1.h"/* contains the. h file of Module 1 in Module 2 */
/* Module 3 implementation file: module3. C */
# Include "module1.h"/* contains the. h file of Module 1 in Module 3 */

Rule 4: If you want to use variables and functions defined by other modules, directly include the header file.
Many programmers like this. When they want to access variables defined by other modules, they add such statements at the beginning of the module file:
Extern int externvar;

Abandon this practice. As long as the header file is completed according to rule 1, when a module needs to access the global variables defined in other modules, it only needs to include the header file of the module.

(4) "array name is Pointer"
Many programmers do not know the differences between array names and pointers. They think that array names are pointers. In fact, there is a big difference between array names and pointers. They need to correctly distinguish them when using them, the differentiation rules are as follows:

Rule 1 array name represents a data structure, which is an array;
For example:
Char STR [10];
Char * pstr = STR;
Cout <sizeof (STR) <Endl;
Cout <sizeof (pstr) <Endl;

Output result:
10
4
This indicates that the array name STR refers to the data structure char [10].

Rule 2 array names can be converted to pointers pointing to objects. They are pointer constants and cannot perform auto-increment, auto-subtraction, or other operations;
Char STR [10];
Char * pstr = STR;
STR ++; // compilation error, prompting that STR is not the left Value
Pstr ++; // The compilation is correct.

Rule 3 points to an array pointer, which is another variable type (with a length of 4 on the Win32 platform). This only means the address where the array is stored;

Rule 4 when the array name is used as a function parameter, In the function body, it loses its own meaning and is just a pointer. Unfortunately, while losing its meaning, it also loses its constant feature and can perform auto-increment, auto-subtraction, and other operations and can be modified.
For example:
Void arraytest (char STR [])
{
Cout <sizeof (STR) <Endl; // output pointer Length
STR ++; // The compilation is correct.
}
Int main (INT argc, char * argv [])
{
Char str1 [10] = "I love u ";
Arraytest (str1 );
Return 0;
}

(5) "32-bit integer"
Whether the integer variable is 32-bit is related not only to the specific CPU architecture, but also to the compiler. In embedded system programming, generally, the number of digits in an integer is equal to the length of the CPU. Commonly Used embedded CPU chips are 8, 16, and 32 characters long, therefore, the length of an integer variable may be 8, 16, or 32. In the next 64-bit platform, the length of integer variables can reach 64-bit.
The length of a long integer variable is generally twice the length of the CPU.
In the design of the data structure, excellent programmers do not define the data structure like this (assuming the Win32 platform ):
Typedef struct tagtypeexample
{
Unsigned short X;
Unsigned int y;
} Typeexample;
They define this as follows:
# Define unsigned short uint16 // 16-bit unsigned integer
# Define unsigned int uint32 // 32-bit unsigned integer
Typedef struct tagtypeexample
{
Uint16 X;
Uint32 y;
} Typeexample;
　　
The data structure defined in this way is very universal. If the data on the above 32 platforms is sent to the 16-bit platform for receiving, you only need to modify the definition of uint16 and uint32 on the 16-bit platform:
# Define unsigned int uint16 // 16-bit unsigned integer
# Define unsigned long uint32 // 32-bit unsigned integer

Almost all of the excellent software design documents define the data structure in this way.

(6) "switch and if... Else... Can be replaced at will"
Switch statement and a bunch of if... Else... Although the combination has the same functions, it gives readers a completely different feeling. If... Else... The logic is the relationship between special conditions and general conditions, the switch gives people the feeling that the relationship between multiple conditions is parallel, and there is no special and general relationship between things, completely "equal ".
For example:
// Process numbers from 1 to 10 separately, and use Switch
Switch (Num)
{
Case 1:
...
Case 2:
...
}
// Special processing of numbers between 1 and 10, using if
If (Num <10 & num> 1)
{
...
}
Else
{
...
}

Many times, although different codes can implement identical functions, they give readers a completely different feeling. For example, an unconditional loop:
While (1)
{
}

Some programmers write as follows:
For (;;)
{
}

This syntax does not exactly express the meaning of the code. We can't see anything from the for (;), only to understand (;;) in the C/C ++ language, it means an unconditional loop to understand its meaning. Readers who do not understand the C/C ++ language can guess that while (1) is an unconditional loop.

(7) "to avoid trouble, make all the member functions in the class public"
When many people compile C ++ programs, they all encounter this situation. Previously, a member function was defined as a class private/protected function, and later I found that I had to call this function from outside, it is easy to change the member function to the public type. Even many programmers simply define their own member functions and member variables as the public type to avoid access troubles.

However, this is a planning failure. In the class design stage, we need to clearly know which of the class's member functions belong to the class's interface and member functions and variables. The general principle is that the interface (Public Member) should be as simple as possible to meet the requirements!

Therefore, do not change private/protected members to public members easily. The real work should be completed in the planning phase.

3. Conclusion
All programmers have to go through a process from confusion to clarity. If you make mistakes in the text, do not commit yourself.

<Http://tech.china.com/zh_cn/netschool/programme/c/656/20050825/12601417.html>