RAII (Resource Acquisition Is Initialization) is the core of C++ idiom. It is about the process and idea of how the object cleans up happens after itself and how a resource belongs to an object lifetime. Why it’s needed anyway, it’s because manually managing resources is easy to get wrong.

In this example:

void readFile() {
    File* file = new File();

    // use the file

    delete file;
}

This is simple, but the programmer has to always remember to call delete, otherwise it can cause problem and to throw an exception error.

RAII works around in these 5 things:

Scope: The region of code where a variable or object can be accessed. Usually {} creates a scope, it is like a boundary, and it’s very important because reaching the end of a scope can cause the objects to be destroyed automatically:

{
    int age = 18;
    std::cout << age;  // works
}

// age cannot be used here

In this code the age can only be exist inside the {} only.

Object lifetime: It is the period during which an object actually can be exists. For a normal local object, it’s lifetime usually matches it’s scope.

{
    File file;
    
    std::cout << "Using file";
}

When this happens, the object is created and it’s lifetime starts, when the } is reached, file is destroyed:

Object created
      ↓
Object lifetime
      ↓
Object destroyed

Constructor: It is a function that runs automatically when an object is created.

class File {
public:
    File() {
        std::cout << "File opened\n";
    }
};

Here File() is the constructor. It’s automatically causes the constructor to execute, it is commonly used to start objects and acquire resources.

Destructor: It is a function that run automatically when an object is destroyed. It has a ~ before the class name. The object reaches the end of its scope and C++ automatically destroys it. They are used to release resources.

class File {
public:
    ~File() {
        std::cout << "File closed\n";
    }
};

In this example:

public:
    File() {
        // open file
    }

    ~File() {
        // close file
    }
};

You don’t have to remember to close the file manually when it goes out of scope.

Resource management: A resource is something your program obtains and needs to eventually release. The problem is that forgetting to release resources can cause problems. If you forget about it, you can leak the resources.

RAII helps in this by putting resource management inside an object:

class File {
public:
    File() {
        // acquire resource
    }

    ~File() {
        // release resource
    }
};

When the scope ends, the destructor automatically releases it.

Object created
      ↓
CONSTRUCTOR runs
      ↓
Resource acquired
      ↓
Object is used
      ↓
Scope ends
      ↓
DESTRUCTOR runs
      ↓
Resource released

This is the core idea behind RAII in C++.

Resources aren’t only memory. They can be Heap memory, Files, Mutex locks, Network connections, Database connections, Sockets, Threads and Operating-system handles.

One interesting part of this is that RAII is not just a technique for you to manually implement with constructors and destructors. Much of modern C++ standard library is build around RAII.

For example, std::fstream manages files:

#include <fstream>

void readFile() {
    std::ifstream file("data.txt");

    // use the file

} // file is automatically closed here

You don’t need to manually call close() in the normal case. When file is destroyed, its destructor handles the cleanup.

std::unique_ptr manages dynamically allocated memory:

#include <memory>

void example() {
    std::unique_ptr<int> number = std::make_unique<int>(42);

} // memory is automatically released here

Without RAII, you have to:

int* number = new int(42);

// use number

delete number;

If an exception or early return happens before delete, the memory can leak. unique_ptr ties the memory’s lifetime to the unique_ptr object’s lifetime.

std::lock_guard applies the same idea to mutexes:

std::mutex mutex;

void work() {
    std::lock_guard<std::mutex> lock(mutex);

    // protected code

} // mutex is automatically unlocked

The general pattern is always the same:

C++ object created
       ↓
Resource acquired
       ↓
Resource used
       ↓
Object destroyed
       ↓
Resource released

Ownership is important because RAII is fundamentally about who is responsible for releasing a resource.

Owning a resource: An object is responsible for managing the resource’s lifetime.

std::unique_ptr<int> number = std::make_unique<int>(42);

number owns the allocated memory. When number is destroyed, this owner is responsible for cleanup.

number destroyed
      ↓
memory released

Borrowing a resource: A borrowed resource can be used but not owned by the object itself using it.

void print(int& number) {
    std::cout << number;
}

print() can use number, but it does not own it. That’s why it should not destroy it.

Owner
  │
  └── resource
        ↑
        │
     borrower

The borrower uses the resource; the owner remains responsible for its lifetime.

Unique ownership: There is exactly one owner of the resource.

The standard C++ example is:

std::unique_ptr<File> file =
    std::make_unique<File>();

Only that unique_ptr owns the File.

You cannot normally copy it:

auto b = file; // Wrong

The ownership can be moved:

auto b = std::move(file); // ownership transferred

Now:

Before:

file ──→ Resource


After:

file     ──→ nothing
b    ───→ Resource

This helps in problems where two objects thinking they are responsible for destroying the same resource.

Shared ownership: Multiple objects genuinely need to own the same resource.

C++ provides std::shared_ptr:

auto a = std::make_shared<File>();
auto b = a;

Now both a and b share ownership.

        ┌── a
Resource ───┤
        └── b

The resource remains alive until the last shared_ptr owning it is destroyed.

a destroyed
     ↓
resource still alive

b destroyed
     ↓
resource released

The above are all the core architecture in terms of how it’s work but with that it’s also create many problems like: If an RAII object owns a resource, blindly copying it can make two objects they they own the same resource.

Example:

File a;
File b = a; // copy

a ──→ File handle 123
b ──→ File handle 123

In this case when a is destroyed it’s closes the handle 123, but again b tries to close the handle 123 again which becomes problem. This is called double-free crashes or other undefined behavior.

For this kind of problem, we can have the objects have uniquely own resources, don’t allow copying, make them movable like this.

File(const File&) = delete;            // no copying
File& operator=(const File&) = delete;

File(File&&) = default;                // moving allowed
File& operator=(File&&) = default;

Exception safety becomes important here. This means RAII protects your resources even when something unexpected happens mostly when an exception is thrown.

Without RAII:

void test() {
    File* file = new File();

    doSomething(); // throws an exception

    delete file;  // never reached!
}

If doSomething() throws, execution jumps out of the function. delete file is skipped, so the resource can leak.

With RAII:

void test() {
    File file;

    doSomething(); // throws an exception
}

When the exception happens, C++ performs stack unwinding:

exception thrown
      ↓
function exits
      ↓
local objects are destroyed
      ↓
File destructor runs
      ↓
resource released

So even though doSomething() failed, File’s destructor still runs. This is one of the biggest reasons RAII is so powerful. RAII makes cleanup automatic even when exceptions interrupt normal execution.

RAII is not the only way of doing these kind of things. There are many alternatives ways of doing the same thing:

RAII vs finally vs garbage collection

RAII is powerful, but it’s important to understand that you should not always treat this to every resource management or program correctness problem. The important thing which RAII guarantees is automatic and deterministic cleanup of resources owned by an object, it’s doesn’t guarantees that the operation performed with that resource is correct.

RAII prevents many leaks, but the resource can still be used incorrectly.

File file("data.txt");

file.write(data);
file.write(data);

The file will eventually be closed correctly, but RAII does not determine whether writing the data twice was a mistake. You can still have invalid operations, incorrect resource usage, incorrect ownership relationships, logic errors, race conditions and deadlocks. RAII solves lifetime management, not general correctness.

RAII does not mean destructors should throw exceptions. The destructor is automatically called when the object leaves its lifetime. The problem with throwing an exception from a destructor is that destruction can happen while another exception is already being handled.

The one thing in which RAII is extremely well at is, how you can correctively release an owned resource when it’s objects lifetime ends.