Dealing with Dynamic Allocation

I like cars. No, actually I don’t like cars, but I accept them as a fact of life, especially speaking as a guy who lives in the U.S.A. And that’s why I use the car in so many of my examples in this book. Love them or not, they are a part of most people’s everyday lives. But on top of that, the automotive industry has had a good 60 years or so to figure out a lot of issues that the computer world is still figuring out. (For example, I haven’t tried to figure this out, but I wonder how long it was until they realized brake lights might be a good idea for a car.)

Now suppose you just bought a brand-new car, and you’re running errands on a Saturday morning, trying to get everything done. You’re at the bank, just leaving. You climb into your car, and when you try to start the car, you hear these words coming from some sort of (annoying) talking device in the car: “I’m sorry. You have started this car 17 times today. You’ll have to wait until tomorrow to start it again.”

Ridiculous, right?

Now imagine if the users of your software tried to open a document and your software announced this rule in the form of an angry message box: “Too many documents open. Please close one before opening another.”

Exactly how many documents can your software open? 10? 16? 32? 64? 100? And what’s significant about these numbers? Well, everybody knows that 10 and 100 are significant. And 10 is a very famous number. Lots of people have heard of it. I’m pretty sure it’s famous because that’s how many fingers a person has. And 100 is just about as famous as 10, because it’s 10 multiplied by itself. As for 16, 32, and 64, these numbers are famous in the computing world because they’re powers of 2. All good numbers.

But let me ask you this: What in the world do these famous numbers have to do with the number of documents your software can open? Nothing! Absolutely nothing! They’re completely arbitrary. But you do have to pick something, right? Suppose you have a Document class, and you have an array that holds pointers to Document objects, like so:

 Document *Docs[100]; 

This, of course, creates an array that holds 100 Document pointers. But that 100 is what some people call a magic number. It’s a number hard-coded into your software that you or another programmer picked arbitrarily. Here are some of the excuses:

• “One hundred documents is more than anyone would ever need open.” (Famous last words.)

• “I don’t want to make the array too big, you know. Memory is expensive.” (No, actually these days memory is not expensive, and arrays of pointers aren’t very big.)

• “It sounds like a good number.” (Magic, right?)

I’ll get to the point:

RULE

Don’t hard-code arbitrary limits in your software.

Instead of using a fixed-size array, use dynamic allocation. You can either code your own linked list, for example, or—better—use one of the container classes in the C++ Standard Library (or the library and types of whatever language you choose). I like to use the vector type:

 std::vector<Document *> Docs; 

That’s it. This creates a container to hold the Document instances. And the container doesn’t suffer from arbitrary limits. (Really, however, the container holds pointers. Please don’t stuff the actual instances into a vector using, for example, std::vector<Document> Docs;. If you do, you’ll end up with copies of the instances inside your container, resulting in copy constructors getting called, new instances getting created, and a big mess.)

Note

If you’re using one of the newer languages such as Python, creating a dynamic array is even easier. In Python, you can simply use the built-in array type, denoted by brackets, [ ]. Or, Borland’s Object Pascal (found in Borland’s Delphi language) has a TList class that works like a charm and has since the day Delphi 1.0 was released in the early 1990s.