1. Goals for this week:
The topics of this week’s lab are a review of C++ programming, C/C++ programming tools, and Unix utilities that you have used before and that you will use in this course. We will go over some of these in lab, but you are responsible for reviewing all of the content on this page. This lab page includes information about:
-
Practice and reminders about C++ programming: statically and dynamically allocated objects, streams, vectors, compiling C++.
-
Practice with
make
and make files. -
Reminders on command line arguments in C and C++ programs and the the
atoi
function. -
Practice with C++ debugging tools:
gdb
andvalgrind
.
2. Starting Point Code
Start by creating a week01
directory in
your cs44/weeklylabs
subdirectory and copying over some files:
# if you have not yet made your cs44/weeklylabs subdirectory do this first:
cd
mkdir cs44
cd cs44
pwd
mkdir weeklylabs
cd ~/cs44/weeklylabs
mkdir week01
cd week01
pwd
/home/you/cs44/weeklylabs/week01
cp ~newhall/public/cs44/week01/* .
ls
3. C++ Programming
We will go over a couple of programs. The first, in arrays.cpp
, will go over
several {cpp concepts}, including:
-
statically and dynamically allocated arrays in C++
-
parsing command line arguments
-
C++ constants
-
C++ stream output, and C
printf
output
We’ll look at this briefly together. Then, you will compile (run make
) and
execute the program with different command line options to make sure you understand how to use
the command line arguments as well as atoi
.
vim arrays.cpp
make
./arrays
./arrays 5 hello there 1234
Second, we will look at cstringExample.cpp
, which will allow us to use
valgrind
to find memory access errors and memory leaks. We will also see a
basic example of using c-strings.
4. gdb and valgrind to debug C++ programs
We are briefly going to go over just a few gdb
and valgrind
features to remind you how to use these tools. I’ll also show you how
to set breakpoint in method functions using '\'' and TAB completion
to easily specify long method function names.
4.1. GDB for C++ program debugging
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.
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
flag to enable debugging).
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:
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.
4.2. Valgrind
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).
Above, we used valgrind
for the cstringExample.cpp
exercise. If you want
some more practice, copy over these files 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
.
4.3. C++ Code Style
Read my C++ Code Style Guide. You do not need to follow my naming style exactly, but pick a convention and follow it. All classes and method functions should be fully commented. 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. Also, if you use globals and constants, comment them as well.
I also really hate wrapped lines. Don’t do it. See my guide for some
techniques to avoid it. If you are using vim, you can copy my
.vimrc
file that has some visual reminders when you get to the 80th
column. Here is some more information vim editor.
5. Other Utilities
We are not going to go over these in class, but here are some
reminders about using make
and makefiles and man
.
5.1. Using man and apropos
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
C++ library functions do not have man
pages, but we will use some C
library functions in lab assignments and some Unix commands, both
of which have man
pages.
5.2. make and makefiles
Here is some information about using make
and makefiles to build
executables:
make and makefiles
We will give you make files with all of your lab assignments, but you
should take some time to be sure you are familiar with using make
, and
be used to running make
to compile your lab code, and make clean
before adding file changes in git
to avoid adding any files to
your repo that are built from source code (i.e. .o
and binary
executable files).
6. Handy References
-
Some C++ Programming Resources and Links including the C++ Style Guide
-
C++ programming tools compiling, linking, debugging C++
-
my help pages other Unix tools and programming links
-
C references in Dive into Systems. (some useful for C++ programming too) Chapter 2: C pointers, command line arguments, C debugging tools (valgrind, gdb for C)