Goals for this week

  • Review of C++ programming, including C++ vector and string, exceptions, and

  • Review of setting breakpoints in C++ method functions in gdb.

  • Intro to SwatDB and reading its on-line documentation, and reading reading class definitions from .h files.

  • Overview of the Lab 2: SwatDB Buffer Manager Assignment.

Starting Point Code

Start by creating a week02 directory in your cs44/weeklylabs subdirectory and copying over some files:

# if you have not yet made your cs44/weeklylabs subdirectory do this first:
mkdir cs44
cd cs44
pwd
  /home/you/cs44/
mkdir weeklylabs

cd ~/cs44/weeklylabs
mkdir week02
cd week02
pwd
  /home/you/cs44/weeklylabs/week02
cp ~newhall/public/cs44/week02/* .
ls

The README.md file includes some instructions for how to run these examples.

C++ Object Oriented Programming

We are going to look at an example program that uses C++ vector and string classes, passes a pointer to a vector to functions, and uses inheritance. The inheritance part is least applicable to your current lab assignment, but we will see it used in some later labs this semester.

Inheritance

We are not going to discuss this much today, but the code you copied over includes an example of inheritance in C++: Worker.[cpp,h] is the definition of a base class representing workers, and Manager.[cpp,h] is a derived class from Worker that adds additional data members and overloads virtual functions.

Some of the lab code you write this semester will use inheritance. This example illustrates some of the features of using derived classes.

Let’s briefly look at some of the code together, then try running it (with and without a command line option specifying the number of Worker objects to create):

make
./workers
./workers 5      # run with a command line arg

Compiling with debug output

In Worker.cpp and Manager.cpp are debugging output statements that print information about which methods are called and the order of destructors invoked in the examples that uses inheritance.

If you look in the Manager.cpp and Worker.cpp files, you will see code like the following that conditionally prints out debugging output based on the value of verbose, which is set by the preprocessor depending on if DEBUG is defined or not:

// if DEBUG is defined set verbose to 1, else to 0
#ifdef DEBUG
static const int verbose  = 1;
#else
static const int verbose  = 0;
#endif

// the value of verbose is used to enable/disable debug output
  if(verbose) {
    std::cout << " In Manager :" << Name() << " constructor\n";
  }

To enable this debugging output, we need to define DEBUG in Worker.h (uncomment the #define DEBUG in Worker.h), and then re-compile and run:

// uncomment to enable debug output
//#define DEBUG

Compile, and when run, you will now see the debug output:

make
./workers

To disable this debugging output, just comment out the definition of DEBUG in Worker.h, and recompile.

gdb breakpoints in methods

Let’s also run this in gdb and see how to set a break point in a method function. Tip: gdb will help us with auto completion and listing options:

gdb ./workers
(gdb) break main
(gdb) run
# use ' to get gdb's help w/finding name of method in which we want to break
(gdb) break 'Manager::   <hit TAB here to see options>

C++ Exceptions

In my_exception.h, there is an example of defining a C++ Exception class (MyException) as well as some examples of throwing (throw) and catching (try/catch blocks) in main_exception.cpp. Exceptions are the main place we will see the use of const and pass-by-reference style parameters this semester (reference parameters have the same semantics as pass-by-pointer parameters, but their syntax look like pass-by-value).

Let’s start by opening my_exception.h and see the class definition, and then main_exception.cpp to see how to catch and throw exceptions.

We will run the program in a few ways:

make
./exceptions   # triggers test for num command line args, prints usage, exits
./exceptions  10  0  # run without any exceptions
./exceptions  10  1  # run w/catch and throw exceptions (std and MyException)

SwatDB

Briefly, let’s review SwatDB by looking at the SwatDB information page. Note its layered design looks a lot like what we have been discussing in lecture.

We will also briefly look at the SwatDB on-line documentation. Note that we can view documentation by class or by file.

For lab assignments, if we give you a .h file in the starting point code, look at that file for the interface that you need to implement vs. the on-line documentation; some lab assignments may implement SwatDB functionality in a slightly different way than it is implemented in the real SwatDB system.

SwatDB Buffer Manager

Next we are going to review the Lab 2: SwatDB Buffer Manager assignment that you read over before lab today.

We are going to do the following:

  1. Overview of the assignment, the classes you need to implement. Use both the details (in the Details section) of methods you need to implement, and the method comments in bufmgr.h to help you determine what and how to implement each method.

  2. Let’s look at the test code.

  3. Let’s open the bufmgr.h class and look at the BufferMap class definition. Together, lets start implementing the insert and contains methods.

    • We are going to send you and your partner to a breakout room to try to finish these two methods after we get started together. If you get these done, move on to implementing other ones before we come back to go over these.

    • You can test out your solution by running the checkpt BufMapTest test suite:

        ./checkpt -s BufMapTest
  4. Next, we are going to get you started on the BufferManager allocatePage method. After looking at the details of this method, you and your partner should come up with pseudocode for its main steps. We will give you just 5 minutes or so to do this. Refine a bit if you have time after coming up with the big steps. We will come back and discuss this together.

C++ Reminders

As you work on the current lab assignment, remember the C++ programming, debugging tools, code style guide, and links to further help from the Wed Lab from Week 1 page.

In particular, if you are still a bit rusty using gdb and valgrind, take some time to review them again so you are comfortable using them to debug this lab. It will save you hours and hours of debugging time to uses these tools, and we will ask you what you discovered from gdb and valgrind about bugs you have in your program that you want us to help you with--we expect that you are using gdb and valgrind to debug.

In-lab pages, as well as the Lab 2: SwatDB Buffer Manager assignment page have links to all kinds of C++ programming resources.

In-lab examples are often useful for testing out C++ features that you may need to use in lab assignments.