Project – Compiler Warnings

In [Stroustrup, 2013], he frequently mentions that for questionably formed C++ statements that the compiler should issue a warning.  This made me realize that only the default warnings in the compiler were being used.  To possibly catch more problems, all of the warnings were enabled using the following GCC compiler options:

-Wall       enable all (well actually most) warnings
-Wextra     enable warnings not enabled by -Wall
-pedantic   enable warnings demanded by strict ISO C++ standard
-Werrors    cause compiler to treat warnings as errors

The last option causes the compiler to abort after issuing a warning instead of proceeding, which will require the warning to be corrected; however, this does not affect warnings from pedantic option, therefore the -pendantic-errors was used instead, which has the same affect.  After adding these options, several warnings were reported, which were of six different types.  Click Continue... for details of these warning types that were corrected.  Since this commit is development related and not specific to any topic, the commit was just made to the develop branch.

[commit bb0124444f]

Function Return Type

There was actually a programming error found in the Error List class with the move column function (used to move an error due to characters being insert and removed in front of the error).  This function does not return a value, but had a integer return type.  The return type was changed to void.

Unused Function Argument

These warnings were mostly in virtual functions with a particular interface and either the base class or derived class didn't require the argument for a function.  There are several ways to remove this warning.  One common way is simply remove the argument name (leaving only the type), or since this removes possible explanation of the code, simply surrounding the argument name in comments.  The GCC compiler has an extension for doing this, but it's ugly and it is an extension.  Another solution is to add a null statement with a void type cast in from of a variables or create a macro to accomplish this as follows:

#define UNUSED(x)  (void)x;

It turns out that there is already a Q_UNUSED macro defined in the Qt header files, so this is the solution selected, except for one instance.  Prefix (++x) and postfix (x++) operator functions were implemented for the Code enumeration.  To distinguish between these operators, both of which only have a single argument, the postfix operator is defined with an extra dummy integer argument.  This dummy argument was given the name "postfix" to identify this as the postfix operator.  Since this name wasn't used, a warning was issued.  For this instance, the name was removed.  (I anticipate that these functions won't be needed once the Table class is redesigned with a better C++ implementation.)

Member Initialization Order

This warning is given if the members of a class are initialized in the constructor in a different order than from defined in the class.  This affected the Expression Info structure used in the table entries, which had one of the member initialized out of order.

Missing Member Initialization

This warning occurs when a structure is initialized, but there are not enough initialization values for all the members of the structure.  Any missing values are set to defaults by the compiler (zeros, null pointers, etc.).   I had chosen to let the compiler initialize extra unused members to defaults.  The missing values were added to eliminate these warnings.

Enumeration Values Not Handled

If not all of the enumeration values appear in case statements, this warning is issued.  There were a couple of instances of switch statements that selected among an enumeration variable.  For these couple of instances, these other enumeration values are not possible, but the compiler cannot determine this, hence the warning.  To eliminate these warnings a blank default was added with a break statement.

Parentheses

The final type of warning is issued for various parentheses issues.  One example of this warning occurs when using an assignment operator (=) in an if statement instead of the equality operator (==).  Another instance that can cause this warning is for when operators are nested whose precedence people often get confused about.  This is the type of warning that occurred.

I personally don't agree with this warning as I think it is clear when parentheses are needed and when they are not, because the operator precedence is well defined and is not unpredictable.  I frequently see programmers insert unnecessary parentheses because they are not sure how the compiler will treat this expression.  However, I think it is more that they are too lazy to learn the precedence of the operators.

This parentheses warning option could be turned off, but I think it is useful for several cases (like the assignment instead of equality operator case, which is an easy mistake).  Also, in IBCP, unnecessary parentheses are kept and reproduced.  Therefore, the decision was made not to fight this warning and just add unnecessary parentheses as required to eliminate the warnings.