1. Ignoring compiler warnings is a bad behavior
- Many programmers habitually ignore the compiler warnings. They think that if the problem is serious, the compiler should report an error instead of a warning, so they habitually ignore the compiler warnings.
- This is incorrect behavior
Two, look at a case
- Now we have the following inheritance system:
class B
{
public:
virtual void f()const;
};
class D :public B
{
public:
virtual void f();
};
- The places that may cause the program to be ambiguous are:
- The f() function is of const type in the base class and non-const type in the derived class, but no error is reported, and the program can still run normally
- Here f() in the base class is not overridden/overridden by the derived class, but is hidden. This is very important
- Some programmers may think that they have rewritten/overridden the f() function of the base class, but in fact there is no (but it is hidden)
- The compiler will only issue a warning. If you ignore this warning, it may affect your subsequent programming
Third, the relationship between warnings and compilers
- Different compilers produce different warnings
Four, summary
- Take the warning messages issued by the compiler seriously. Strive for the honor of "no warning" at the highest (most demanding) warning level of your compiler
- Don’t rely too much on the compiler’s warning capabilities, because different compilers treat things differently. Once ported to another compiler, the warning messages you originally relied on may disappear.