Thoughts on C++ and Programming for 559

While the focus of this page is on resources to help you learn C++ if you have not learned it already, there are some general comments that might be helpful as you try to prepare to do your projects for CS559.

For this class, you will need to program all of your projects and assignments in C++ (or C).

This is not a statement about the language, or the appropriateness to doing graphics. It's more a statement about what is a convenient environment for us to teach graphics in. Just as we chose to give lectures in English, despite the fact that other languages could have been used, we chose to give programming assignments and projects in C++.

The might be a problem if your previous programming experience was in a different programming language. This is increasingly the case as we move our introductory programming courses to Java.

First, it is definitely possible to do well in CS559 if it is your first exposure to C++. Many students (OK, some students) did very well. In fact, knowledge of C++ beforehand is not necessarily a good predictor of how well students do in 559.

That said, learning C++ at the same time that you are learning the graphics material will be a challenge. Plan to devote some extra time to it.

To be honest, the biggest problem for most students transcends the language: its the ability to build and debug non-trivial programs. For many students, 559 is the first time that they have to write a program that is too big to wrap their head around. Learning to write complicated programs is harder than picking up C++ if you already know Java.

Some Resources for Learning C++

Since a lot of people will ask...

The department offers a "course" (CS368) to teach student C++ after they have learned Java. It is a self-paced web tutorial. You can work through it without registering (and getting credit). You can access the tutorials from http://www.cs.wisc.edu/~hasti/cs368/.

Books

When I learned C++ (1989), I went to the bookstore and there were 2 books. So when I tell you the book that I used to learn C++, you have to take the recommendation with a grain of salt.

My favorite C++ book is Lippman's C++ Primer. (published by Addison Wesley). With each version, it seems to double in size (this time it added a second author). When I got the first version it was a compact little volume. To be honest, I think it gets worse as it grows bigger.

Two other books that have been recommended to me are Wang's "Standard C++ with Object Oriented Programming" and Deitel & Deitel's "C++, How to Program." I have not used either of these, so no promises. Another well known book is Stroustrap's "The C++ Programming Language." This book was first (Stroustrap is the "inventor" of C++). Like Lippman (who was 2nd) this book doubles in size with each version. .

One thing that I dislike in C++ books is when they spend more time telling you their programming philosophy, rather than the constructs of the language. There seems to be no avoiding this.

Another problem with C++ books is that they like to show off how you can use the complicated features of the language to do tricky things. There are whole books on these kinds of things (that are probably better at it). My opinion is that you are best off learning the basics first, and then moving on to fancier things later.

Web Tutorials

Aside from CS368, there are a bunch out there. In fact, if you type in some C++ topic to your favorite search engine, you will find something. (I did this the other night when I couldn't remember how Templates worked). While you might wade through a pile of junk (this is the web), you might find something good.

Some Hints

This is based not only on my own experience, but on my experience teaching CS367 back when it was taught in C++, and in helping 559 students write their first programs.

Think before you code. That might sound obvious, but its amazing how often people do this. It's really the key to doing anything non-trivial.

Avoid using fancy features of the lanuage - until you are really sure that you need them. Templates, exceptions, and operator overloading are complicated things to understand, and very difficult to use productively. Most times when people make use of them, they are not helping themselves out.

Read other people's code. Reading code is an important skill - that is amazingly un-taught in the CS curriculumn. Look for good code, and read it - see how the author makes use of C++ features (or doesn't as the case may be). The example code for 559, and the source code to FlTk are good things to look at.

Learn to use the debugger. "Print Statement Debugging" is still a useful tool, but often its not the most effective one for squashing your bugs.

If its available, make use of a memory leak/memory bug finder. In general, a memory bug is a sign of a design flaw. You should squish these bugs early because they only become harder to track down.

Have a look at one of these "fancy" C++ books. You may not want to use all of their complicated tricks, but they will get you thinking of how the language works and can be used. For some examples on the web, a few of the chapters of "Effective C++ Programming" is here. The 4 examples of chapters are all good advice (although, you should not have the need for tip 10 in 559).

Break down the problem into stages. Don't write 1000 lines of code and then test it. Build a little piece, test it, and then add another piece to it, test it, ... You will have to design your solution to be built this way. Design top-down, but debug bottom-up.

Try to understand what your program is doing before debugging. The "make random changes until it work" paradigm really doesn't work as your program gets bigger. Understand each piece individually, and then how the pieces fit together. Design top-down, but debug bottom-up.

Think in an object oriented way. Just because you use C++, or even use the OO features in C++, you can still not be doing Object-Oriented Programming. Object-Oriented is a way of thinking. Try to encapsulate functionality when possible. This helps break big problems into lots of smaller ones.

Think before you code. (yes, its worth saying again).

Good luck!