Last week, we saw how data structures can be useful in solving "real world" problems. We also saw how test-driven development can help us build robust data structures.
Today's exercise has two parts:
The first part of this week's exercise is to practice thinking about variables, addresses. and values. If you have not already done so, open part1.cpp and look it over. The first part of this exercise is to draw an accurate diagram of the memory allocated to these variables, complete with memory addresses.
To accomplish this, you can use one or more output statements to display the address of each variable. To display the address, you can either use the address-of operator (&) that we discussed in class, or use an appropriate pointer variable.
Add statements to part1.cpp that will display the address associated with each variable.
Using the information this yields, use a spreadsheet (or lined paper if no spreadsheet is available) to draw an accurate diagram of the memory in which all of these variables are stored, including the pointer variables. Your diagram should show your memory as one or more vertical columns, using each line of the diagram to represent 1 byte. Show the hexadecimal address of each byte, and clearly indicate which bytes are associated with which variable.
For example, if there were three variables x, y, and z, and you found them to be associated with addresses 0x1000, 0x1002, and 0x1003 respectively, then your diagram might look something like this (but a lot bigger):
Questions. On your diagram, answer the following questions:
One other issue is that the GNU C++ compiler does not seem to like to display the addresses of char variables. A workaround is to trick the compiler by converting the char variable address's type from char* to a type that the compiler will display. One way to do this is to cast the address from char* to void* as follows:
cout << "charVal1: " << static_cast<void*>(&charVal1) << endl;
To avoid the tedium of typing all those hex addresses into your spreadsheet, you may find this program hexList.cpp to be useful. To use it, you will need to first record the hexadecimal numbers that Experiment1 produces (e.g., save them in a text file), and then identify the maximum and minimum of those numbers. These are the 'highest' and 'lowest' memory addresses where your variables reside. (These are not necessarily the first and last values.)
Once you have made a note of those addresses, you are ready to use the hexList.cpp program. Download it, create a new project, import, compile, and run it, and it will let you generate ascending or descending sequences of hex numbers, which you can copy/paste into your spreadsheet.
(This program uses getline() to read in each number you enter as a string, and then converts the digits in that string into a number, so be careful that you do not enter any spaces when you enter the number.)
When your spreadsheet is done, save it in an Excel-compatible format into your lab2 folder for this exercise.
In this second part of today's exercise, we will explore how pointers can be used to process dynamically-allocated arrays. We will also start using the Eclipse debugger. A debugger can be invaluable in debugging your programs in this course, so I highly recommend you practice using it anytime your program contains a logic error.
Getting Started. Begin by "commenting out" the entire main() function in part1.cpp. Then import part2.cpp, array.h, and array.cpp into your project. Open each of these files, verify that they compile without error; then continue.
Array processing. Run the program in part2.cpp, and compare its output with the statements it contains. In particular, note the following:
double *a1 = new double[SIZE];In this statement:
delete  a1;returns the storage to which a1 points back to the system. To return a dynamically-allocated array to the system, the delete must include the subscript () symbol, or else only the first element of the array will be returned to the system.
double a2[SIZE];The memory for this array is fixed when the program is compiled, and it cannot be changed as your program runs. Such arrays are called statically allocated arrays (or just static arrays). Dynamically allocated arrays are much more flexible than statically allocated arrays, but require the programmer to explicitly manage memory (i.e., allocated and deallocate it).
Using the Debugger. Before we fix average(), we want to introduce you to a tool specially designed to help you find logic errors in your program -- errors where your program compiles correctly, but does not run correctly. This tool is appropriately called the debugger, and Eclipse's C++ plugin uses the GNU debugger, which is named gdb.
To use gdb from within Eclipse, go to the Run menu and choose Debug... (Alternatively, you can just click the Debug button -- -- which should do the same thing.) Depending on how Eclipse is configured, you may or may not see a Select Preferred Launcher dialog, containing a list of ways to launch the debugger. If this dialog appears, select Standard Create Process Launcher from the list.
Eclipse should then should then display a Debug dialog that looks a lot like the Run dialog. If the Debug button at the bottom is not dimmed, click it. (If it is dimmed, click the Debugger tab and check that a debugger is selected in the Debugger combo box that appears.)
The debugger uses a different perspective than the normal C/C++ perspective, so Eclipse will ask you to confirm that you want to change the perspective. (Click Yes.) Eclipse will then
Below the Debug tab is a code window displaying your program. Note that the first statement in the main() function is highlighted, and there is a blue arrow beside that statement:
Whenever your program is suspended, Eclipse displays this blue arrow to indicate the statement that will be performed next when your program resumes execution (see below).
To the right of the Debug area you should see a Variables tab, above a window in which you should see listed the variables in your main() function. Note that the value of each variable is displayed.
Being able to view all of a function's variables and their values as your program is executed is one of the most useful aspects of a debugger.
Between the Debug tab and the Variables tab is a debugging toolbar:
For our immediate purposes, the most important buttons on this toolbar are:
Check the value of a1 in the Variables tab; then press the Step over button again. You should again see the blue arrow advance to the next statement. Does a1 change value?
At this point, your blue arrow should be at the assert() statement. Use the Step over button to execute that statement in its entirety.
Your blue arrow should now be at the statement that calls the initialize() function. If we were to press Step over again, this statement (and function) would be executed in its entirety. So instead of doing that, press Step into. Your code and Variables areas should change to indicate that you are now "inside" the initialize() function. Look over your Variables area, and then press Step over several times. Note how the values of your function's variables change as each statement is performed. Note also how easy it is to trace the repetition of the function's for loop!
Continue to use Step over until control returns to the output statement in the main() function. Use Step over to step over this output statement. Then use Step into to step into the print() function. Again, note the change of the Variables area, to reflect the variables within print(). If you click the triangle next to the name of parameter a, you can view not only the value stored in a (an address), but can also view the value at that address. With a "opened up" in this way, click Step over enough times to execute the a++; statement. What effect does the a++; statement have on the values shown in the Variables tab?
Click Step over several more times, watching the effect each statement has on the variables.
Anytime you are inside a function, the Step return button can be pressed. When you press this button, the remainder of the function is performed. When control returns to the function's caller, your program suspends again. Press it now, and control should return to the statement in main() containing the call to average().
The Step over and Step into buttons are the two most frequently used buttons in debugging. Others that are also useful include:
To set a breakpoint, click on the left margin of the code window next to the statement where you want execution to suspend. A blue circle will appear in the margin to mark the breakpoint.
To unset a breakpoint, click on its blue circle.
Use the debugger to step through the remainder of the code in part2.cpp. Note in particular that the same operations work equally well on either dynamically or statically allocated arrays. If you "open up" a2 and a1, does the debugger display the same information or different information about each array?
To leave the debugger and return to the normal C/C++ perspective, click the Terminate button, then use the Open Perspective button (near the upper right corner of the screen) to change from the Debugger perspective back to the C/C++ perspective.
Congratulations! You've just used the Eclipse debugger!
Your Turn. Even without the debugger, you should be able to see that something is wrong with the average() function. For the rest of this exercise, you are to "fix" this function, without using the subscript () operator! Use what you have learned in this lab to write this function to compute the average of the values in the array using a pointer variable and pointer operations instead of the subscript operator.
Hint: How does the print() function access each entry of the array it is passed?
Copy your lab2 folder into your /home/cs/112/current/ folder, so that the grader can check your spreadsheet, your modified part1.cpp, and your average() function (defined in array.cpp and called in part2.cpp).
If time permits, you may begin working on this week's project.
CS > 112 > Labs > 02