Lab 2 - Basic Classes and Debugging Classes with gdb

The purpose of this lab is to practice adding features to a basic class and to learn how to debug class objects in gdb.

You may work in groups of two on this assignment. Be sure to put both names in the comment section at the top of the source code so both lab partners get credit.

Download (wget) or copy lab2.cpp to your lab directory. This is the StudentRecord class given in lecture with the added feature of using a define to set the length of the name C-string. Modify this code to add an integer array with three elements called exam in the member variables. Then add for loops to both inputStudent() and printStudent() to input the exam grades and output the exam grades.

Compile your code with debugging enabled: 

g++ -g -o lab2 lab2.cpp
You must use the -g option any time you wish to debug with gdb. The gdb utility is the debugger that comes with the GNU compilers such as gcc and g++. It allows you to either step line-by-line through your code or to examine a special file called a core dump. A core dump file is a special file that may be generated when your code crashes with an error such as a Segmentation fault. It contains enough information about the state of the program that you can usually use a core dump file to determine why the program crashed while running. By default on Sleipnir, a core dump file will NOT be generated when your code crashes.

Today we will focus on line-by-line debugging. Refer to the gdb lab for CMPS 215 for more details about using gdb beyond what is covered in this lab. To start gdb in line-by-line mode, issue the following command: 

gdb lab2
This will start gdb and present you with the gdb prompt. All interactions and debugging are done via commands at the gdb prompt. The first important command when debugging in line-by-line mode is to tell gdb when to "break" by setting a breakpoint. Generally, a breakpoint will be set to a line of code or a function where you suspect there is a problem and you want to debug that code in depth.

To set a breakpoint, you give either a function name or a line number. When dealing with member functions, you have to give both the class name and the function name. Here are examples of setting breakpoints on a line number, global function and member function respectively: 

break 30
break main
break StudentRecord::inputStudent
Note how we use the class scope tag to break at a member function. Once you have set breakpoints, you tell gdb to start running your code by giving the following command: 
run
The program will then execute until a breakpoint is reached, a crash occurs or the program exits, whichever comes first. It will then return you to the gdb prompt. If it has reached a breakpoint, you can now examine the variables in the current scope with the print command. For example, if you have a breakpoint in main, you can look at the enrolled or size local variables. When inside inputStudent, you can look at the member variables. Some examples for how to use print are: 
print size
print enrolled                # From main()'s scope
print enrolled[0]             # From main()'s scope
print enrolled[0].name        # From main()'s scope
print name                    # Only works inside one of the class functions
print exam[0]                 # Only works inside one of the class functions
While at a breakpoint, you can also investigate how the code executes line-by-line by "stepping" through the code. The command to do this is 
step
This will show you the line that is being executed and then return you to the gdb prompt. You can then use the print command to see how the line affected the variables. You can repeat the step command as many times as you want.

When you are done looking at that segment of code line-by-line, you can tell gdb to run until the next breakpoint with the command 

continue
When you are done with debugging, you exit gdb with the command 
quit
If your code has not yet exited (returned out of main), quit will prompt you to be sure you really wish to exit gdb.

Add the exam member variable to lab2.cpp and email me the updated source code. Play around with gdb commands to get familiar with the debugger if you have not used it before.