Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the errors that the C++ compiler cannot catch". The content in the article is simple and clear, and it is easy to learn and understand. Now please follow the editor's train of thought slowly and deeply. Let's study and learn what are the errors that the C++ compiler cannot catch.

C++ is a complex programming language full of subtle traps. There are almost countless ways to screw things up on C++. Fortunately, today's compilers are smart enough to detect a considerable number of such programming traps and notify programmers with compilation errors or compilation warnings. In the end, if handled properly, any errors that the compiler can detect won't be a big problem, because they will be caught at compile time and resolved before the program actually runs. In the worst case, the errors that a compiler can catch will only cost programmers some time, because they will find ways to solve the compilation errors and correct them.

Those errors that cannot be caught by the compiler are the most dangerous. Such errors are not easy to detect, but can lead to serious consequences, such as incorrect output, data corruption, and program crashes. With the expansion of the project, the complexity of code logic and numerous execution paths will mask these bug, resulting in the emergence of these bug only intermittently, which makes this kind of bug difficult to track and debug. Although most of the list in this article is just a review for experienced programmers, the consequences of such bug tend to be enhanced to varying degrees depending on the size and commercial nature of the project.

1) the variable is not initialized

Uninitialized variables is one of the most common and easy mistakes in C++ programming. In C++, the memory space allocated for variables is not completely "clean" and is not automatically zeroed when space is allocated. As a result, an uninitialized variable will contain a value, but there is no way to know exactly what the value is. In addition, the value of the variable may change each time the program is executed. This has the potential to cause intermittent seizures, which is particularly difficult to track. Take a look at the following code snippet:

If (bValue) / / do An else / / do B

If bValue is an uninitialized variable, the judgment of the if statement cannot be determined, and both branches may be executed. In general, the compiler prompts for uninitialized variables. The following code snippet raises a warning message on most compilers.

Int foo () {int nX; return nX;}

However, there are some simple examples that do not produce warnings:

Void increment (int & nValue) {+ + nValue;} int foo () {int nX; increment (nX); return nX;}

The above code snippet may not generate a warning, because the compiler generally does not track to see if the function increment () has assigned a value to nValue.

Uninitialized variables are more common in classes, and initialization of members is generally done through the implementation of the constructor.

Class Foo {private: int Oops; public: Foo (); int GetValue () {return massibValue;}; Foo::Foo () {/ / Oops, we forgot to initialize m_nValue} int main () {Foo cFoo; if (cFoo.GetValue () > 0) / / do something else / / do something else}

Note that m_nValue has never been initialized. As a result, GetValue () returns a junk value, and both branches of the if statement are likely to execute.

Novice programmers usually make the following mistakes when defining multiple variables:

Int nValue1, nValue2 = 5

The intention here is that both nValue1 and nValue2 are initialized to 5, but in fact only nValue2 is initialized, nValue1 has never been initialized.

Because the uninitialized variable may be any value, it will cause the program to behave differently each time it executes, and it is difficult to find the root cause of the problem caused by the uninitialized variable. The program may work properly on one execution, it may crash the next time it is executed, and the next time it may produce incorrect output. When you run a program under the debugger, the defined variables are usually zeroed. This means that your program may work fine every time under the debugger, but it may collapse intermittently in the release! If you encounter such a strange thing, the culprit is often uninitialized variables.

2) Integer division

Most binary operations in C++ require that both operands are of the same type. If there are different types of operands, one of the operands is promoted to a type that matches the other. In C++, the division operator can be thought of as two different operations: one on an integer and the other on a floating-point number. If the Operand is a floating-point type, the division operation returns the value of a floating-point number:

Float fX = 7; float fY = 2; float fValue = fX / fY; / / fValue = 3.5

If the Operand is of integer type, the division operation discards any decimal part and returns only the integer part.

Int nX = 7; int nY = 2; int nValue = nX / nY; / / nValue = 3

If one Operand is integer and the other is floating-point, the integer is promoted to floating-point:

Float fX = 7.0; int nY = 2; float fValue = fX / nY; / / nY promoted to floating point, division operation will return floating point value / / fValue = 3.5

There are many novice programmers who will try to write code like this:

Int nX = 7; int nY = 2; float fValue = nX / nY; / / fValue = 3 (not 3.5!)

The intention here is that nX/nY will produce a floating-point division operation because the result is assigned to a floating-point variable. But in fact this is not the case. NX/nY is first evaluated and the result is an integer value before it is promoted to floating point and assigned to fValue. But the decimal part has been discarded before the assignment.

To force floating-point division between two integers, one of the operands needs to be converted to a floating-point number:

Int nX = 7; int nY = 2; float fValue = static_cast (nX) / nY; / / fValue = 3.5

Because nX is explicitly converted to float, nY will be implicitly promoted to float, so the division operator will perform floating-point division, resulting in 3.5.

It is usually difficult to say at first glance whether a division operator performs integer division or floating-point division:

Z = x / y; / / is this integer division or floating point division?

But the use of Hungarian naming can help us dispel this confusion and prevent errors from happening:

Int nZ = nX / nY; / / integer division double dZ = dX / dY; / / floating point division

Another interesting thing about integer division is that the C++ standard does not specify how to truncate the result when an Operand is negative. As a result, the compiler is free to truncate up or down! For example,-5max 2 can be evaluated as either-3 or-2, depending on whether the compiler rounds down or 0. Most modern compilers round to zero.

3) = vs = =

It's an old problem, but it's valuable. Many C++ novices confuse the meaning of the assignment operator (=) and the equality operator (=). But even programmers who know the difference between the two operators can make keystroke errors, which can lead to unexpected results.

/ / return 1 if nValue is 0, otherwise return nValue int foo (int nValue) {if (nValue = 0) / / this is a keystroke error! Return 1; else return nValue;} int main () {std::cout

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.