Resource Leaks and Strong Resource Safety

Many programs acquire something they must later give back. The three examples the source names are memory, a thread of execution, and a file. When that work is done by hand with raw pointers, every acquisition needs a matching release, and the programmer must remember to write that release at every place the code could leave. Forgetting one of those releases is how a resource leak happens: a resource is acquired and never given back.

Keep one question in mind as you read this article: when the code is finished with a resource, which piece of code is responsible for releasing it? The answer changes depending on whether you use a raw pointer or a resource handle, and that difference is the central idea here.

Consider a simple scenario. A function obtains a resource, uses it for some work, and then finishes. With a raw pointer, the function holds a plain address. Nothing about that address says whether the resource still needs to be released, or who should do it. The release is a separate action that the programmer must place correctly, and it must happen on every path out of the function.

This scenario is not a claim that raw pointers are useless. The problem is that a bare pointer does not tell the program who owns the resource or when it should be released, so that responsibility has to be spelled out everywhere the function can end.

With a resource handle, the same scenario is organized differently. The handle is the object that holds the resource, and its job includes releasing it. The function works with the handle rather than with the bare pointer. Responsibility for the release is attached to the handle, not spread across the lines of code that happen to use the resource.

The phrase alternative to pointers is important. A handle does not usually replace the idea of a resource. It replaces the way the program would otherwise hold a resource and track it. The resource still exists, and something still has to manage it. A handle takes over that management role so that the rest of the code does not have to.

When a handle wraps a resource, three things are involved: the application code, the handle, and the resource itself. Read the diagram from top to bottom. Application code works with the handle. The handle is the object that stands in front of the resource and manages it. The resource is the thing being held, such as memory, a system thread, or a file handle.

The answer to the central question is now clear. The resource is held by the handle, and the handle is the object responsible for giving it back. The application code uses the resource through the handle, but it does not need to be the piece of code that performs the release. The source describes the handle as the object whose job includes releasing the resource it manages.

A handle is a normal object with a lifetime. The timeline below follows one handle-managed resource from acquisition through release. The important point is the step near the end: the release is tied to the handle's lifetime ending, not to a separate line the programmer must write at each exit.

Because the release is tied to the handle's lifetime, the programmer does not need a separate release step at each place where the function can end. Whether the function finishes normally or leaves early, the handle's lifetime comes to an end and the resource it manages is released. The source does not walk through every control-flow case, but this is the mechanism that lets handles eliminate leaks.

The source names several familiar standard-library types that are resource handles. Each one holds a different kind of resource, which shows how broad the idea is. The list below is the set the source gives, with the resource each one holds.

Notice that vector appears even though many people think of it as a container. The source classifies it as a handle because it holds memory on the program's behalf. The same classification applies to thread and fstream. Unique_ptr matters for a related reason: the source notes that the standard-library smart pointers are themselves resource handles, so a unique_ptr is an example of the same pattern discussed here, not a separate topic.

The phrase general notion of a resource matters. The source does not limit the idea to memory. It names memory, system threads, and file handles as examples of resources. Strong resource safety aims at all of these, so a leak in a thread or a file is as much the target as a leak of memory.

Read the two columns side by side. In the raw pointer column, the release is a step the programmer must remember to perform, and if it is skipped on some path, the resource leaks. In the handle column, the release is a consequence of the handle's role as the resource's manager. The source describes this as making pointers disappear into resource handles, so that the code using the resource no longer has to carry the bookkeeping itself.