# How do I deal with memory leaks?

Bjarne Stroustrup's answer to "How do I deal with memory leaks?" in his C++ Style and Technique FAQ is one paragraph long, and most of it is a link: *"By writing code that doesn't have any."* The rest of the entry expands what that means in practice — and is the canonical short statement of the discipline that became [[raii]].

## The argument

Conscientiousness doesn't scale. If `new`, `delete`, and pointer arithmetic are sprinkled across a large program, the volume of bookkeeping eventually exceeds what any developer can hold in their head, and leaks or stray pointers become certain rather than possible. Stroustrup's claim is that this is independent of how careful you are — it's a property of the code shape, not the programmer.

The fix is to push allocation and deallocation behind types that own their resources. The standard containers (`std::string`, `std::vector`) are the canonical example: they manage memory for their elements better than hand-written code "without disproportionate effort." The FAQ contrasts a small `vector<string>` program — no `new`, no `delete`, no casts, no size limits — against the same logic written without containers, where leak-freedom would require deliberate proof.

## The 1981 anecdote

The most concrete part of the entry is a one-line claim from 1981: by reducing the number of objects he had to track explicitly from "many tens of thousands to a few dozens," Stroustrup turned a Herculean task into something manageable. This is the original quantitative argument for what later became RAII — not a philosophical preference, but a working set bound on what humans can correctly track.

## Resource handles for the residue

When allocation can't be hidden inside an existing container, Stroustrup's prescription is a resource handle. The FAQ uses `auto_ptr` (long since superseded by `unique_ptr` and `shared_ptr`, but the principle is identical) and gives a deliberately leaky example to contrast against:

```cpp
S* f()                  // who is responsible for deleting this S?
{
    return new S;
}

auto_ptr<S> g()         // explicitly transfer responsibility
{
    return auto_ptr<S>(new S);
}
```

The point isn't the smart-pointer machinery; it's that ownership becomes part of the type. You cannot accidentally drop the result of `g()` without the destructor running. The principle generalizes — *"think about resources in general, rather than simply about memory"* — to file handles, locks, sockets, and anything else with a paired acquire/release.

## The fallback clause

The entry closes with one concession: if you must use code "from elsewhere, part of your program was written by Neanderthals, etc.," fall back on a memory leak detector or plug in a garbage collector. This is framed as a remediation, not a default. The cultural posture of C++ — that GC is for code you can't control rather than the language baseline — is visible in that one sentence.

## Why this still matters

The FAQ entry is old (the `auto_ptr` example dates it to before C++11), but the framing has aged better than the syntax. Modern C++ uses `unique_ptr` and `shared_ptr` instead of `auto_ptr`, and the standard library has grown more containers, but the underlying claim — that leak-freedom is a code-shape property, not a discipline property — is exactly the discipline that [[simplified-model-of-fil-c]] tries to enforce *mechanically* in C/C++ via shadow capabilities and a backing GC. Stroustrup's answer is the social contract; Fil-C is the runtime enforcement.

It also rhymes with [[no-silver-bullet]]: explicit memory management is *accidental* difficulty, and the standard containers are an attack on that accidental complexity. The 1981 reduction from thousands to dozens is the kind of order-of-magnitude productivity gain Brooks claimed no single development could produce — and which RAII arguably did, just for one specific category of bug.