RAII is the C++ idiom that ties the lifetime of a resource (memory, an open file, a held mutex, a network socket, a GPU handle) to the lifetime of an object. A constructor acquires the resource; the destructor releases it. When the object goes out of scope, the cleanup happens on its own, no matter how the scope exits. This chapter introduces the idiom: what it means, why it matters, what a hand-written RAII wrapper looks like, and when one is required.

The name is awkward, but "Resource Acquisition Is Initialization" means: acquire the resource in the constructor, release it in the destructor. The object owns the resource, and the language guarantees that destructors run when objects go out of scope. With this rule, cleanup is the compiler's responsibility, not the programmer's.

That single shift fixes a surprising number of bugs:

Every one of those bugs has the same root cause: a resource was acquired manually and released manually, and the release step got skipped or duplicated. RAII removes the manual release step entirely. Only one place frees the resource (the destructor), and the language guarantees it runs exactly once per object.

What is missing matters most. There is no fclose call in main. The braces around FileHandle log(...) define a scope, and when the scope ends, log's destructor runs and closes the file. That destructor would run whether the scope ended normally, by return, by break, or by an exception travelling through. The cleanup is part of the object's lifecycle, not part of the surrounding code's logic.

To see why RAII is worth the small upfront investment, consider the same job written without it. The function opens a file, writes a couple of lines for an order receipt, and closes the file.

The empty-customer path leaks the file handle. The fix looks reasonable until more paths are added, each requiring its own fclose.

There are now four paths and fclose appears three times. Add an exception (say std::fprintf could throw via a user-defined stream) and the picture gets worse, because none of those fclose calls run on the throw path. The function would have to wrap everything in try/catch to clean up a single file handle.

With RAII, the same function looks like this:

No fclose calls anywhere. Every return triggers f's destructor on the way out. An exception thrown by any line in the function does the same thing. The body of the function says what the function does and nothing about cleanup, because cleanup is no longer part of the function's job.

An RAII wrapper has a very small job description:

That is the contract. Everything else about RAII is a special case of those three rules.

Rule 3 deserves a second look. A wrapper for a new-allocated buffer that uses the compiler-generated copy constructor produces two copies holding the same raw pointer. When both destructors run, both call delete on the same address, and the second call corrupts the heap. That bug is called a double free, and it has the same root as the leak bugs from earlier: manual ownership tracking is fragile.

This chapter disables copying explicitly with = delete. Doing it right (either deep copy or move-only with proper move operations) belongs in the Rule of Five chapter in the Modern C++ section.

This is the rough shape of every well-behaved RAII type: ctor acquires, dtor releases, copy operations are either disabled or carefully written. This BufferOwner returns below in the cart example.

Files fit RAII naturally because the C standard library returns a raw FILE* from std::fopen and requires a matching std::fclose to release it. That requirement is the kind of manual release step RAII is designed to retire.

A slightly more complete FileHandle supports reading and writing, refuses to be copied, and reports failure during construction.

Three details deserve attention. The constructor throws when fopen fails, so the caller never receives a FileHandle that looks valid but is not. The destructor never throws; throwing from a destructor during stack unwinding is the trap covered in the Exception Handling section. The copy operations are deleted, which prevents producing two FileHandle objects pointing at the same FILE*.

The raw() method exists because code sometimes needs to hand the underlying handle to a C API (like std::fread or std::fwrite). Exposing it is fine. Allowing external std::fclose calls is not. RAII keeps ownership in one place and lets the owner share read-only access when needed.

A mutex is a synchronisation object that is "locked" before touching shared data and "unlocked" afterwards. Forgetting to unlock is a disaster: the next thread that wants the mutex will block forever, and the program deadlocks. If the code that should have unlocked it threw an exception, the unlock never happens. This is RAII's other classic use case.

The concurrency section covers std::mutex and std::lock_guard in depth. The version below is a stripped-down LockGuard written by hand so the RAII pattern is unmistakable.

The body of addItem is two lines of real work, and the locking concern stays out of sight. If cart_items += 1 threw (it cannot here, but in a more complex operation), the LockGuard destructor would still run during unwinding and the mutex would still get released. The function would never deadlock the system on its way out.

The standard library's std::lock_guard follows the same pattern. Writing one by hand is unnecessary in production code; the point here is that the entire idiom fits in twenty lines.

Consider a cart that stores up to N line entries in a contiguous integer buffer (each entry is a product code, or a quantity for that line). The buffer comes from new int[N] and must be released with delete[]. A BufferOwner wrapper turns that pair into a single object with predictable cleanup.

What happens if the loop body throws partway through, say at line 2? The answer is the same as with FileHandle. The BufferOwner destructor runs during stack unwinding, delete[] is called, the heap memory comes back, and the program continues without a leak. The cleanup story is identical for files, locks, and memory because RAII gives all three the same shape.

Wrapping a raw resource in an RAII class adds nothing to the runtime in optimised builds. Calling cartLines[0] = 1001 compiles to the same instructions as writing through a raw pointer. The wrapper is a compile-time concept; at runtime, the cost is the resource, not the wrapper.

The argument for RAII is clearest in a comparison of two versions of the same function under an exception. Consider a routine that allocates a buffer, does some work that could throw, and is supposed to free the buffer at the end.

Hand-rolled cleanup, broken:

When the throw fires at i == 2, control leaves the function before delete[]. The heap memory allocated for buffer is leaked. The compiler issues no warning. A tool like Valgrind or AddressSanitizer would catch it at runtime, but only when the right test is run.

Hand-rolled cleanup with `try`/`catch`:

This version is correct, but it has grown two delete[] calls and a rethrow. Every owned resource in the function would need the same scaffolding. A function that owns three resources ends up with nested try blocks or a fragile chain of cleanup checks. Most code does not look like this; it leaks instead.

RAII version:

The RAII version is the original "broken" version with one type change: int* buffer = new int[count] became BufferOwner buffer(count). The free path became correct without any extra code in the function body. If the function later grows three more resources, each gets its own RAII wrapper and the function body stays clean.

This is why the C++ Core Guidelines say "almost always RAII." Every owned resource (memory, file, socket, lock, GPU handle, OS handle of any kind) should live inside an object whose destructor releases it. The standard library already provides RAII wrappers for the most common resources: std::unique_ptr and std::shared_ptr for heap allocations, std::fstream for files, std::lock_guard and std::scoped_lock for mutexes, std::jthread for threads.

A diagram helps cement the picture. Each RAII object has a lifetime that begins when control passes its declaration and ends when control leaves the enclosing scope. The resource it owns has the same lifetime, by construction.

The two oranges (ctor and dtor) bracket the lifetime of both the object and its resource. Nothing in the middle has to think about cleanup, because the brackets are guaranteed. The "leave scope" step is intentionally written as "normal return or throw" because both paths end up running the destructor. That symmetry is the central idea of the idiom.

A second diagram covers the case where a single function owns several RAII objects at once, which is the normal situation for any non-trivial code. Consider processOrder owning a LockGuard, a BufferOwner, and a FileHandle at the same time.

The destruction order on the right side is file, buffer, lock. That is the reverse of the construction order on the left, which is the rule for local objects. A function that acquires the lock first releases it last, after every protected resource has been cleaned up. The language enforces that order with no extra code, which is another reason RAII composes so well.

The Best Practices section covers this in detail. The moment a destructor does real work, the compiler-generated copy constructor and copy assignment operator probably do the wrong thing. They copy the raw pointer or handle bit-for-bit, producing two objects that both think they own the same resource. When both go out of scope, the destructor runs twice. With a new-allocated buffer, that is a double free; with a file handle, a double close.

The classical rule of thumb: if any one of the destructor, the copy constructor, or the copy assignment operator is written, all three are almost certainly needed. That is the Rule of Three, and in modern C++ it has been extended to the Rule of Five to cover move construction and move assignment. The detailed chapter lives in the Best Practices section.

For this lesson, the simple way to stay out of trouble is to delete the copy operations whenever an RAII destructor is written. That at least turns "subtle runtime bug" into "obvious compile error." Move support (the modern way to make ownership transferable) is covered alongside the Rule of Five.

The guideline is unusually firm for a C++ recommendation. Every owned resource should live inside an RAII wrapper. The standard library already provides wrappers for the most common resources:

That covers most of the resources a typical C++ program touches. For a resource that the standard library does not wrap (an OS file descriptor, a GPU handle, a database connection from a third-party C library), write an RAII wrapper for it once and use the wrapper everywhere else.

The payoff is not just fewer leaks. The rest of the code stops thinking about cleanup at all. A function that takes a std::unique_ptr<Order> by value owns the order; when the function returns, the order is freed. A function that constructs an std::lock_guard on entry releases the mutex on exit. A function that opens an std::ofstream for a receipt closes it when the stream goes out of scope. None of those functions need a single line of explicit teardown. That is what "almost always RAII" provides.