Comp 15

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.

Unix Reference

You will be working on our department GNU/Linux computers in lab and to do and turn in your work. If you took Comp 11 here at Tufts, you will already have some familiarity. It's a good idea to be familiar with basic Unix commands (Linux is kind of Unix operating system). You will need to create directories, navigate among directories, create, copy and remove files, compile files, etc. One good reference is

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

Comp 11 Review Material

Here are notes on various topics from a previous version of Comp 11. If you are new to Tufts or C++, or if you're just a little rusty, please review these topics.

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 of our code (all?) 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 that contains an introduction to Unix/Linux, including documentation and examples of lots of Unix commands as well as introductions to emacs and vi.

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.

Formatting code in Emacs

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

C-c . linux
It will be easier still if you change the .emacs file in your home directory to make this apply every time you edit a C file. If you don't have a .emacs file in your home directory, then just make it, and put this stuff in. Here is what I have in my .emacs file, and you should add this to your .emacs file right away:
;; Setting default styles for Java, C, and C++
(setq c-default-style
      '((java-mode . "java")
 	(c-mode    . "linux")
	(c++-mode  . "linux")
 	(other     . "gnu")))

(setq-default indent-tabs-mode nil)  ;; Uses spaces rather than tabs 
                                     ;; for indentation
This will set the indentation depth to 8 spaces, get curly braces to behave, and force emacs to use space characters rather than tab characters for indentation. The last bit is important if you want your code to look the same to other people (like graders!) who may not have the same tab settings you do.

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.

make and Makefiles

Here are some notes on make


Here are some notes on templates, including some examples.
Mark A. Sheldon (
Last Modified