C++ Blog

Automatic memory management -- no panacea

Thu, 07 Feb 2008 11:17:51 -0500

One of the loudest criticisms I hear about C++ is that it doesn't have garbage collection. In other words, whenever a program allocates memory, some other part of that program has to figure out when to free it.

Of course, that figuring out can often be automated. As an obvious example, every standard-library container class keeps track of its own memory and frees it as needed. Nevertheless, it is hard to resist the belief that automatically freeing memory would make life a lot simpler for C++ programmers.

When code and documentation disagree

Mon, 21 Jan 2008 11:45:47 -0500

When you find that your code's behavior doesn't match the documentation, which one do you change?

The trouble with testing

Wed, 02 Jan 2008 10:06:27 -0500

There is a school of thought that says that when you set out to write a program, you should write the tests first. Your goal is then to write the simplest program that passes the tests. Once you have done so, you're done.

This approach is certainly appealing. In particular, having automated tests that capture as much as possible of a program's desired behavior is an excellent idea. But what if a program has to have a characteristic that you don't know how to test?

Another bug that should never happen

Tue, 18 Dec 2007 12:21:30 -0500

I was just reading an article on the website of a major newspaper that I'd rather not name. I finished the first page, clicked on the second, and got:

Sorry for the interruption. Hello! You have been chosen to participate in an important survey from , a respected 3rd party research company. This is for RESEARCH PURPOSES ONLY. We are not selling anything. Your answers are grouped anonymously.

followed by "yes" and "no" buttons.

Computers versus programs

Tue, 11 Dec 2007 11:25:30 -0500

A strong influence on how I think about programming is a 1971 book by Edsger Dijkstra named A Discipline of Programming. Most of this book is a series of elegant solutions to simple problems, but parts of it are philosophical essays, some of which have stuck with me for the more than 35 years since I've read them.

Divide and botch

Wed, 21 Nov 2007 10:00:47 -0500

A well known software design principle is "Divide and conquer"--the notion that by dividing a large problem into smaller problems will yield a solution where the overall problem might be too hard to solve. This strategy is often combined with recursion. For example, one widely used sorting algorithm is to divide the data to be sorted into two approximately equal pieces, sort each piece, and finally merge the two sorted pieces.

However, sometimes the division doesn't have quite the intended effect. Each individual piece of the problem might be solved correctly, but combining the solutions yields a surprise.

Least surprise in elections

Sat, 03 Nov 2007 14:48:36 -0500

We have seen that it's not easy to collect several players into teams that have well-defined strength. Such surprises come up even when we're not dealing with teams. Indeed, they happen even in seemingly straightforward situations such as elections.

Least surprise in tournaments

Sat, 03 Nov 2007 14:26:47 -0500

Now that we've seen how trying to combine plausible-sounding rules can surprise APL programmers, let's look at a more mundane example: a tournament to find out which of several teams is the strongest. We shall learn that it is hard to avoid surprising results, even in simple cases.

The principle of least surprise can be surprising

Tue, 16 Oct 2007 10:39:43 -0500

It's hard to study software design for long without coming across the principle of least surprise, sometimes called the principle of least astonishment. Both terms refer to the idea that a system should cause as little surprise as possible for someone who doesn't already know how it behaves.

This idea is a good one most of the time. However, sometimes there is a good and simple reason for behavior that is surprising at first glance. In such cases, following the principle of least surprise may introduce extra complexity into the system and make its behavior more surprising in the long run.

The hazards of warning messages

Tue, 02 Oct 2007 11:36:07 -0500

Experienced programmers usually think that warning messages from compilers are a Good Thing. After all, such messages let us know when we have written programs that might not do what we expected, and sometimes save us from hours of debugging.

Some bugs shouldn't happen--but do anyway

Wed, 12 Sep 2007 15:11:10 -0500

My friends tell me that I'm good at making things break in surprising ways. Here's an example.

The zeroth rule of debugging

Thu, 06 Sep 2007 13:41:35 -0500

My last post generated a few comments, one of which made a suggestion for what should be the second rule of debugging. I agree with that suggestion, and will elaborate on it later. But there is another rule that is even more important--so important that I see little alternative to calling it the zeroth rule.

The first rule of debugging

Thu, 23 Aug 2007 11:00:20 -0500

If you've been programming for more than, oh, a few minutes, you've discovered that your programs don't always work as you intended.

Most beginners' first reaction when they make such discoveries is to think that there is something wrong with the compiler. After being disabused of that notion, they will reluctantly go looking for the problem.

However, my experience is that many programmers, especially beginners, make a critical mistake when they go on their bug hunts.

A whopper of a lesson in user-interface design, part 3

Wed, 22 Aug 2007 14:06:44 -0500

To recap: I wanted to upgrade my computer's graphics card. First the computer manufacturer recommended a card that wouldn't fit, then they replaced it with a card that fit but required a power-supply upgrade, and the new power supply didn't fit.

Is the third time the charm?

A whopper of a lesson in user-interface design, part 2

Fri, 10 Aug 2007 13:09:30 -0500

In Part 1, I tried to upgrade my graphics card, only to be steered wrong by my computer manufacturer's website. The saga continues with my trying to swap the wrong card they had sold me for the right one.