Week 1:

The topics of this week's lab are a review of C and C++ programming tools and utilities that you have used before and that you should use when solving lab 0. We will not talk about all of these in lab, but this page contains some links to resources about:

1. man and apropos
2. make and makefiles
3. git revision control software
4. review of C++ debugging tools: gdb (and ddd) and valgrind
5. C style strings

All the links to documentation are also available off my help pages

---

Start by creating a cs44 subdirectory in your home directory, and then create a weeklylabs/w01 subdirectory into which you will copy over some files:

  mkdir cs44
  cd cs44 
  pwd
  mkdir weelylabs
  cd weeklylabs
  pwd
  cp -R ~newhall/public/cs44/week01 .
  cd week01
  ls

Here is some information about how to read manual page using man and how to find commands and library functions using apropos: man and apropos

Try looking at the man page for fork to see how it is telling you information about the fork function: how to call it; what header file(s) to be included to call it; and what the function does and what its return value(s) are.

% man fork
# or, I could specify the man section...I don't need to for fork:
% man 2 fork   # the man page for the system call fork in section 2 of the manual

Here is some information about using make and makefiles to build executables: make and makefiles You will use a makefile in lab 1.

We will use git for lab assignments in this class. Lab repos will be hosted on the college's git hub server, and you will push your solution prior to the due date to turn it in.

If you have not used git, or if it has been awhile, here is some information about how to use it: using git

In the code you copied over are two subdirectories with test files for gdb and valgrind. We are going to go over just a couple of these, but see my gdb and valgrind documentation (both linked to below) for more information about using gdb and valgrind and try out some more examples.

We are going to look at some features of gdb for debugging C++ programs. In particular, looking at a stack trace, moving between frames to examine parameter and argument values, and examining runtime state of a segfaulting program. Again, you can use ddd, but I'm going to show you the gdb commands running gdb.

Here is a directory of files you can copy over that can be used to test out some gdb features:

cd ~/cs44/weeklylabs
cp -r ~newhall/public/gdb_examples .
cd gdb_examples

First, run make to build the executables (note they are all compiled with -g).

Let's look through a couple of the example programs in gdb, following along in my GDB Guide.

We are going to look at badprog and segfaulter in gdb. These are listed in the "Sample gdb sessions" part of my gdb guide under run 1: debugging badprog and run 2: debugging segfaulter.

Let's also try setting a break point in the C++ example code you copied over. Make use of gdb's tab completion to list the names of class methods.

Up the page on this guide are lists of common gdb commands and some examples of how to use them.

cd into the valgrind_examples subdirectory.

Valgrind is a tool for finding heap memory access errors and memory leaks in C and C++ programs. Memory access errors are often very difficult bugs to find, and valgrind helps you easily find errors like reads or writes beyond the bounds of a malloc'ed array, accessing free'ed memory, reading uninitialized memory, and memory leaks (not freeing malloc'ed space before all variables referring to it go out of scope).

Here are some files you can copy over that can be used to test out valgrind:

cd ~/cs44/weeklylabs
cp -r ~newhall/public/valgrind_examples .
cd valgrind_examples

To use valgrind, just compile with -g, and run valgrind on your program (the Makefile has this already):

make
valgrind ./badprog

The output at first seems a bit cryptic, but once you see the basics of how to interpret it, it is extremely helpful for finding and fixing memory access errors. Let's look at my Valgrind Guide to see how to interpret some of this valgrind output. This guide contains links to other valgrind resources, and the README file in the code you copied over lists some command line options for running valgrind.

Some more information on debugging tools for C++: C++ programming tools: gdb and valgrind

Lab assignments will be in C++, making use of its support for object oriented programing, streams, and exceptions, but will use of some C features of C++, including C-style strings in Lab 0.

Here are some C and C++ programming resources:

• C strings
• Links to C++ Programming Resources
  (Read my C++ Code Sytle Guidelines. You must submit well-commented code to receive full credit on lab assignments).
• Links to C Programming Resources

Read my C++ Code Style Guide. You do not need to follow my naming style exactly, but pick a convention and follow it. With the exception of very simple getter and setter methods, all classes and method functions should be fully commented. Also, if you use globals and constants, comment these as well. You should write complete function comments in both .h and .cpp file. One way to do this is to write them in the .h file first, copy the .h file contents to the .cpp as a starting point for writing method function implementations.

I also really hate wrapped lines. Don't do it. See my guide for some techniques for avoiding it.