Comp 11

Reference Material

This page is for reference material that you may find helpful. This page is not exhaustive and it never will be. You can help by letting me know of resources that you find helpful and would like to recommend to your colleagues.

Working Remotely

You can do all your work on the department lab machines, but if you want to work remotely on your own computer, you'll need a program that lets you interact with the department server (the same program you'll use in lab): ssh (which stands for Secure SHell).

C++ References

GNU/Linux and EMACS

You might consider installing GNU/Linux on your computer. The Ubuntu distribution is popular, and I have successfully installed it on a laptop with relative ease. Running it in a VM is reasonable. Any flavor of Linux should work for most things, and, for that matter, most code will run under any Unix (such as MacOS, which uses a Unix system descended from BSD Unix).

Larry Greenfield wrote a useful Linux Users' Guide.

Here is a useful Unix/Linux Command Reference (thanks to Margaret Gorguissian for this link).

Norman Matloff has also written Emacs: The Software Engineer's “Swiss Army Knife.” Larry Greenfield wrote a handy GNU Emacs reference card that you can carry around with you. There is also an XEmacs reference card. (Thanks to Karl Schults for sending this link.)

If you prefer to use vi/vim, you can look at this brief tutorial and cheat sheet, and you can configure vim to use the Linux coding style, too! (Thanks to Roland Crosby for these links.)

This is one of the most hilarious rants ever written! (Scroll down to the post by Patrick LoPresti.) Enjoy this related cartoon. You may also want to peruse these quotations.

Programming Style

There are many approaches to programming style. To help you get started, we will provide a Comp 11 C++ Style Guide, which you should follow for your C++ programming assignments.

Formatting code in Emacs

You can set Emacs's indentation style to to various things. At the moment, I'm using k&r for C++. For an idividual editing session, you can type

C-c . k&r
It will be easier still if you change your .emacs file to make this apply every time you edit a C file. Here is what I have in my .emacs file, and you should add this to your .emacs file right away:
(setq c-default-style
      '((java-mode . "java")
 	(c-mode    . "linux")
	(c++-mode  . "k&r")
 	(other     . "gnu")))

When you are typing your code and you come to the end of a line, type C-j, rather than a return. If you do this, Emacs indents the next line automatically according to the indentation rules. Alternatively, hitting Tab will indent the current line according to the current rules. If you have edited a function and ruined the indentation (or you fear you may have brace or parenthesis problems), you can indent an entire block by placing the curser over the opening curly brace of the block and typing M-C-q. You can also select a region and then type M-x Indent-region.


All non-trivial programs have bugs (and most trivial ones do, too). C compile-time errors are often not helpful, and run-time errors are mostly just “segmentation fault” or “bus error.” Well-written, well-organized code is easier to debug. When debugging, one should think. Many students will reflexively respond to the compiler message “attempt to make int from pointer without a cast” by inserting a cast. Usually, that's not going to fix the problem.

Search engines like Google have really changed debugging: it is very common now to cut and paste an error message one doesn't understand into a search engine and look it up that way. But that is not enough.

You will benefit by becoming familiar with a proper debugger. Runtime error messages are generally uninformative, and sometimes, a flood of print statements won't do the trick. gdb is the GNU debugger and has a line-oriented interface. It has a GUI front end called ddd, which has documentation available via the web and in a downloadable PDF document.

Here is a brief lab with exercises for learning gdb.

Think of a debugger as a replacement for the interactive read-eval-print loop in interpreted environments that you may have used in languages like Python, ML, or Scheme.

Mark A. Sheldon (
Last Modified 2018-Mar-28