Lab - Eclipse
This lab will give you the opportunity to explore some of the kinds of problems that static analysis tools can help you with. This will be a fairly basic exercise. We won’t be installing any new tools for this lab – just making some better use of an already familiar tool, the
We will look at some more advanced tools later in the sememster.
Set up a C++ project to use in this lab. You can use any IDE, though if you have been working through the earlier assignment on Eclipse, it would probably make the most sense to use that. But you can use Code::Blocks or even emacs. You are going to be doing a lot of stepping though error messages and examining the associated code, so pick somethings that does that job well.
Your C++ code for this project should be reasonably complicated. It should involve multiple .cpp files and some use of classes. It might even be something that you never got working correctly, though it should compile.
Build (compile) your project in the normal fashion. Most IDEs will display somewhere the compilation commands that they are running on your behalf. Take note of these. (In Eclipse, you can find these in the
Consoletab of the bottom central window.)
Also take note of any compiler warnings that were issued. (Presumably you did not get actual errors that owuld have prevented compilation.) Step through these warnings and take note of the kind of things the compiler is bringing to your attention.
At the end of this exercise summarize your results on the discussion board.
-Wall flag, added to a
g++ compilation, causes the compiler to emit warnings for a number of practices that, in the opinion of the
g++ designers, are both questionable and easily avoided.
Some of the things checked by
- out of bound accesses to arrays, when compiled with
- use of C++11 features when the explicit option for these has not been supplied
- use of
charin array subscripts
- abuse of enumeration types in comparisons
- bad formats in
- possibly uninitialized variables
If your project build does not already include
-Wall, add it to the compiler options. (See Changing Compiler Options below.)
Rebuild your project. (You may need to clean/clear the project first to force a full rebuild, because you have not actually touched any of the source code.)
If your project build already included
-Wall, try removing it and rebuilding. Any changes?
Walk through the messages now. Do you see any changes? If not, try adding one of the problems described earlier as being under the purview of
-Walland rebuild again.
Take particular note of any messages that indicate a true potential problem with your code. Take note also of nay false alarms, things that you know are OK even though they were flagged. (Keep your mind open, at least, to the possibility that there may be potential problems that you aren’t aware of.)
Any surprises? Discover any hidden problems? Or, maybe, just find some of the warnings you got to be inexplicable? Post about your experiences in the Hallway Forum.
-Wextra adds still more checks, including warning for empty loop and
if bodies, comparisons between signed and unsigned integers, and parameters to functions that are never used in the function body.
- Repeat the process from -Wall, this time adding
-Wextrain addition to
Weffc++ adds warnigns for a number of issues from Scott Meyers’ Effective C++ and More Effective C++.
These include warnings if you fail to implement your own version of the copy constructor and assignment operator for classes that have dynamic allocation. (You should recall discussions of the C++ Rule of the Big 3 from your earlier courses.) Also flagged are
operator= implementations that fail to return
*this, and the use of assignment rather than initialization within constructors.
- Repeat the process from -Wall, this time adding
-Weffc++in addition to
5 Closing Thoughts
These options can give you early warning of potential problems, but only if you actually read and consider the warning messages. The struggle with most static analysis regimens is to balance the value of the legitimate warnings against the annoyance of wading through many false alarms.
6 Appendix: Changing Compiler Options
Read on if you are not familiar with the process of changing the options used to compile C++ code in your favorite IDE.
If you are using emacs as your IDE, you are probably using a make file to control your build.
Look in the make file for the actual
g++ commands and add the desired option there.
It’s a common style among writers of make files to invoke the compiler via a variable name, usually “CXX”, e.g.,
CXX=g++ ⋮ $(CXX) -o $@ -c $*.cpp
The reason is that this make file can then easily be modified to use a different compiler by changing that variable. In fact, it can be changed directly from the command line. For example, if I wanted to generate a Windows executable when running the compiler on a Linux box, I say
to use a Windows cross-compiler instead of the normal
It’s also common to package the compilation options in a variable. For example, I often use
CPPFLAGS, in conjunction with a rule like:
CXX=g++ CPPFLAGS=-g -std=c++11 %.o: %.cpp $(CXX) $(CPPFLAGS) -MMD -o $@ -c $*.cpp
So any change to the
CPPFLAGSvariable would update all compilations generated by this make file.
To change C++ compilation options in Eclipse, much depends on whether you are using the Eclipse build-in project manager or a separate make file to control the build. If you are using a make file, then follow the instructions given above.
If you are working with the built-in manager, go to the Project menu and select
Properties, `C/C++ Build“, ”Settings“, then the ”Tool Settings“ tab. You can then select the option flags you want directly in the ”GCC C++ Compiler“ ”Warnings“ or ”Miscellaneous“ area. Note that when you select an option in one of these areas, then it gets added to the summary ”All options“ at the ”GCC C++ Compiler" area.
Project menu, select
Build Options, then
Settings. You can then try to select your desired option form the description in
Compiler Flags or type it in directly under