Container Overview

Many programs need to hold more than one value at a time. A list of student scores, a set of file names, or a queue of tasks all share the same need: a single object that holds a group of related items. This article introduces that idea under the heading Container Overview and names the two things to understand first: the elements a container holds, and range checking, the way we make sure we only reach into the parts of a container that really exist.

Keep a single question in mind as you read. If you ask a container for a position, how can you tell whether anything is actually stored there? The rest of this article builds the mental model you need to answer that question reliably.

The relationship between a container and its elements is one to many. One container can hold many elements, and each element belongs to that container. You can think of the container as a box at the top of a diagram, with each element hanging beneath it as one of the things it holds. The elements are what make the container useful: without them, the container would have nothing to offer.

Elements and range checking are linked ideas. Elements are what a container holds, and range checking is how you determine whether a particular location within the container refers to one of those elements. You need a set of elements before you can ask whether a position falls inside it, so the elements come first.

In this illustration the container is a small list of four student scores. Positions 0 through 3 each hold one element, while position 4 has nothing stored in it. The numbering here is a convention chosen for the illustration; the point is that the container's elements define which positions are real.

A request for a position is only useful when that position exists. Asking a container for something beyond the elements it holds means asking for something that is not there. Range checking is the habit of verifying the request before relying on its result. Treat out-of-range requests as cases you must handle, rather than assuming the element exists.

The reasoning a range check follows always has the same three steps: identify the range, compare the request against it, and decide. Work through the illustration from earlier, a container holding elements at positions 0 through 3, and trace two different requests.

Now change the request to position 2. The same three steps apply. The range is still 0 through 3. Is 2 at least 0? Yes. Is 2 at most 3? Yes. The comparison shows the position lies within the elements held, so the range check passes. The container was not changed by the check; it only confirmed that position 2 points at a stored element.

Read the flowchart from the top. For the request 4, the first comparison passes because 4 is not below 0, so the path moves to the second decision. There, 4 is not at most 3, so the path ends at the out-of-range outcome. For the request 2, both comparisons pass and the path ends at the valid outcome. In both cases the container itself is left exactly as it was.

Most range errors happen at the edges of the range. Compare two requests that sit right next to each other: one that is just inside the last element and one that is exactly one past it. The difference between them is small, but the outcome is completely different.

Both requests are one step apart, yet one passes and one fails. This is why the check must compare against the actual last held position rather than an approximate one. Stopping one short or reaching one past is exactly the kind of boundary mistake that a careful range check prevents.

Use the same container from this article, holding four elements at positions 0 through 3. Before checking the answers, apply the three steps to each request below: identify the range, compare the request against it, and decide whether it is valid.