7.3. Compile Errors and Warnings


Compile errors and warnings

A compile error happens when the compiler reports something wrong with your program, and does not produce a machine-language translation. You will get compile errors. Everybody does. Don't let them bother you. They are usually relatively easy to fix.

If you request warnings (which you definitely should do), the compiler will also warn you when it sees something that does not look right. A program that has warnings but no errors will be translated to machine language, but you should be suspicious of it. Pay attention to the warnings. They usually indicate mistakes.


General advice on dealing with compile errors

If you get a compile error or warning, do not panic. Read what the compiler says. Then, based on that, examine your program to determine what the real error is.

What the compiler says is based on its view of what is going on. Remember that the compiler does not know what you are trying to accomplish, and its advice needs to be weighed against that. The compiler often does not tell you exactly what is wrong. Do not treat getting rid of compile errors as a process of getting your program to compile, no matter what. The goal is to get it to compile, while making sure that it does what you want it to do.

Some programmers prefer to use integrated development environments (IDEs) that contain an editor, compiler, debugger and documentation manager all in one. Those can be very convenient, but do not use one as a crutch. If you are typing your program and the IDE marks the line as bad, do not feel compelled to fix it right away. The IDE cannot tell you what to type because it does not know what you are trying to accomplish.

In short, a compiler or IDE makes a good adviser but a terrible boss. You must be the boss. Do not let the compiler or IDE bully you into writing something that is not what you want to write. Instead, find a way to express what you want in terms that the compiler accepts.

When you look at an error, the compiler or IDE shows you the line where it detects the error. But the error is not always on that line. For example, if you have omitted a semicolon on line 12 then the compiler might detect an error at line 13. Always widen your view to include prior lines.

Sometimes one error leads to others. One missing semicolon can cause the compiler to write a hundred error messages. Do not panic just because you see a lot of errors. Concentrate on fixing the first error. Then compile again. If you are positive that the first error would not cause others, then take a look at the others too.


Some common compile errors and warnings

Missing or extra semicolon

If you omit a semicolon, you will get an error. Similarly, an extra semicolon can sometimes lead to an error. This is a very common error. Fix it and move on.

Syntax error

If you get a general syntax error, carefully inspect the line where the error is reported and the line before that one.

Sometimes, the previous line is in an included file. Be sure to check the included file, if the error does not appear to be in the line where the error is reported.


Wrong number of arguments

If the compiler complains that you have used the wrong number of arguments in a function call, check your function definition carefully. What did you really want to say? What are the correct arguments? Never just throw out arguments without thinking because there are too many, and never add arguments without thinking about what they should be.

Type error

If you get a type error, look carefully at what you have written. The compiler tells you which thing has the wrong type. Ask yourself what that thing really should have been.

Undeclared variable

If you use a variable that has not been created, you will get an error. Do not just create that variable to make the compiler stop complaining. Ask yourself what is really wrong. If you do need to create that variable, then create it. But you might have simply mispelled its name.

Duplicate variables

If the compiler complains about a duplicate variable, it might be because you have written something like
  int x = y;
where you meant
  x = y;

Using = instead of ==

If you request warnings, the compiler will warn you when you use = instead of ==. You will get a message something like the following.
  warning: suggest parentheses around assignment used as truth value [-Wparentheses]

Failure to return a value

A function that has a non-void return type should return a value no matter what it does. If you get a warning such as
  warning: no return statement in function returning non-void [-Wreturn-type]
or
  warning: control reaches end of non-void function [-Wreturn-type]
then the compiler is telling you that the function can return without doing a return statement (by reaching the end of the function definition). Look at the function definition and make sure that it always returns an answer.