Your goal here is to get to know gdb, a "debugger" program that can help you find the problems with your programs. Debuggers can't help you until your program compiles, but once you have eliminated all compiler errors, a debugger can be one of your most valuable tools.
Today, you'll use gdb to (1) watch a variable, (2) single-step through a program, and (3) set breakpoints. All three of these operations should become clear shortly.
Save the program odds.cpp in your account, and compile it as follows:
g++ odds.cpp -g -Wall -o odds
The -g flag tells the compiler to include debugging information in the executable file "odds".
Open odds.cpp in your editor, and move the window off to the side.
In the terminal window, run the command
gdb odds
At the gdb prompt, type "list". You should see the first 10 lines of your program. Type "list" again. You should see the next 10 lines. Next, type "list 8". You should see the lines of code around line 8.
Line 7 should be the one that reads "int N = 10". Set a breakpoint on this line by typing "break 7" at the gdb prompt.
Run the program by typing "run" at the gdb prompt. The program will run until your breakpoint and stop there.
Type "print N" at the gdb prompt. Also do "print sum" at the gdb prompt. What values are currently in N and sum? Why?
At the gdb prompt, type "step". What happens? What is the value of N now? What is the value of "sum" now?
Keep stepping your code. How do N and sum change as you move through your code?
Run the program again, but this time type "next" instead of "step" to move through your program. What is the difference between "next" and "step"? Why is this useful for debugging?
Run the program again, and this time use "step" again to step into the SumOfOdds function. After you have stepped through a couple of iterations of the while loop, type "cont" at the gdb prompt. What does this command do? Why is this useful for debugging?
Type "help list" or "help step" or just "help". There's lots more information available. Type "quit" to quit.
Try gdb on one of your own programs. Note that you can list the code in a member function by typing something like "list Queue::Add".
There's an interesting tutorial on gdb by Andrew Gilpin at http://www-2.cs.cmu.edu/~gilpin/tutorial/. He guides you through the discovery of the cause of a segmentation fault in a templated linked list class. If you want more experience with gdb, check it out.
You can also take a look at the official gdb documentation.
Read through the description of makefiles at http://www.mathcs.carleton.edu/courses/course_resources/cs117/project-management/index.html.
Make a new directory somewhere and save copies of the following in the directory: Makefile, main.cpp, functions.cpp, and project.h. Take a look at each of the files. If you have questions about anything in any of these files, either figure out the answers or save the questions for class time.
Now, cd to the directory, type "make release", and watch what happens. Do an "ls" to see what new files (if any) there are. Run the program.
Type "make debug" and run the program. Did it do what you expected?
What happens if you just type "make"? Why?
Type "make clean". Does it do something sensible?
Save Makefile2 as Makefile (over the top of the old one), and predict what's going to happen when you do "make release". Do "make release", and take a look at the contents of the directory.
Finally, make a small change to one of the .cpp files, and type "make release" again. Which files got recompiled, and which didn't? Now modify project.h slightly and do "make release". Which ones got recompiled this time, and why? Why would this kind of Makefile structure be superior to the simpler structure for a large project (dozens of files or larger)?