Language

since C++11

Beginner

Manage Resources Safely with RAII

Learn how RAII ties resource cleanup to object lifetime so you never leak memory, files, or locks again.

By the end of this page, you will understand why resource leaks happen, how C++ destructors prevent them automatically, and how to write your own RAII wrapper and use standard library tools like std::unique_ptr and std::lock_guard to manage any resource without ever writing cleanup code twice.

What and Why

Imagine you borrow a library book. Normally you return it when you are done. But what if you get distracted halfway through the day and never get around to it? That book is gone from circulation — leaked — even though it still exists somewhere.

Programs face the same problem with resources: open files, allocated memory, network connections, locked mutexes. Every resource you acquire must eventually be released. If you forget — or if your code exits early through a return statement or an exception — the resource is gone.

Many languages rely on a garbage collector to handle at least memory. C++ has no garbage collector. You are responsible.

RAII (Resource Acquisition Is Initialization) is the C++ idiom that solves this. The core idea fits in one sentence:

Tie the lifetime of a resource to the lifetime of an object — acquire in the constructor, release in the destructor.

C++ guarantees that an object's destructor runs the moment the object goes out of scope, even when an exception is thrown. That guarantee is the engine behind RAII.

Step by Step

The problem without RAII

Here is code that opens a file without any safety net:

cpp

#include <cstdio>

void process(bool fail_early) {
    FILE* f = std::fopen("log.txt", "w");

    if (fail_early) {
        return;               // file handle is never closed — leak
    }

    std::fputs("done\n", f);
    std::fclose(f);           // only reached on the happy path
}

int main() {
    process(true);   // leaks the file handle
    process(false);  // works correctly
}

Every branch that does not reach std::fclose leaks the handle. Add more branches, more early returns, or any exception, and the problem multiplies.

Wrapping the resource in a class

Move the cleanup into a destructor so it cannot be skipped:

cpp

#include <cstdio>
#include <stdexcept>

class FileHandle {
public:
    explicit FileHandle(const char* path, const char* mode)
        : file_(std::fopen(path, mode))
    {
        if (!file_) throw std::runtime_error("could not open file");
    }

    ~FileHandle() { std::fclose(file_); }

    FILE* get() const { return file_; }

    FileHandle(const FileHandle&)            = delete;
    FileHandle& operator=(const FileHandle&) = delete;

private:
    FILE* file_;
};

void process(bool fail_early) {
    FileHandle f("log.txt", "w");  // resource acquired

    if (fail_early) {
        return;   // destructor runs here — file is closed safely
    }

    std::fputs("done\n", f.get());
}   // destructor runs here too — always closed

int main() {
    process(true);
    process(false);
}

The = delete on the copy constructor and copy assignment prevents accidentally duplicating the file handle, which would cause a double-close crash. You will see this pattern in every correct RAII class that owns a unique resource.

Using the standard library

C++11 ships with ready-made RAII types for the most common resources. You rarely need to write your own:

cpp

#include <memory>
#include <iostream>

struct Connection {
    explicit Connection(int id) : id_(id) {
        std::cout << "Connection " << id_ << " opened\n";
    }
    ~Connection() {
        std::cout << "Connection " << id_ << " closed\n";
    }
    int id_;
};

int main() {
    auto conn = std::make_unique<Connection>(7);
    // conn->id_ is accessible here
}   // unique_ptr destructor deletes Connection automatically

Output:

cpp

Connection 7 opened
Connection 7 closed

No delete. No leak. Scope does the work.

Common Patterns

Pattern 1 — dynamic memory with `std::unique_ptr`

cpp

#include <memory>
#include <vector>

struct Mesh {
    std::vector<float> vertices;
    explicit Mesh(int n) : vertices(n, 0.f) {}
};

std::unique_ptr<Mesh> load_mesh(int vertex_count) {
    return std::make_unique<Mesh>(vertex_count);
}

int main() {
    auto mesh = load_mesh(1024);
    // mesh is deleted automatically when it goes out of scope
}

Pattern 2 — mutexes with `std::lock_guard`

cpp

#include <mutex>
#include <iostream>

std::mutex g_mutex;

void safe_print(const char* msg) {
    std::lock_guard<std::mutex> lock(g_mutex);  // mutex locked here
    std::cout << msg << '\n';
}   // lock_guard destructor releases the mutex here, no matter what

int main() {
    safe_print("hello from RAII");
}

Without lock_guard you would need a matching unlock() call in every exit path — easy to miss under error conditions.

Pattern 3 — file streams from the standard library

std::ifstream and std::ofstream are themselves RAII types: they open on construction and close on destruction.

cpp

#include <fstream>

int main() {
    std::ofstream out("notes.txt");  // file opened
    out << "C++ RAII is elegant\n";
}   // destructor closes and flushes the file

What Can Go Wrong

Mistake 1 — Thinking raw pointers manage themselves

cpp

// WRONG — raw pointer, no RAII
#include <string>

void bad() {
    std::string* s = new std::string("oops");
    return;   // s is never deleted — memory leaked
}

int main() { bad(); }

cpp

// RIGHT — unique_ptr owns the string
#include <memory>
#include <string>

void good() {
    auto s = std::make_unique<std::string>("great");
}   // deleted automatically

int main() { good(); }

A raw pointer is just an address. It has no destructor. Only hand raw pointers to RAII types.

Mistake 2 — Trying to copy a uniquely-owned resource

cpp

#include <memory>

int main() {
    auto a = std::make_unique<int>(10);
    // auto b = a;           // compile error — unique_ptr is not copyable
    auto b = std::move(a);  // correct: transfer ownership
    // a is now empty; b owns the int
}

std::unique_ptr is move-only. The compiler stops you from accidentally creating two owners for one allocation. If you genuinely need shared ownership, use std::shared_ptr.

Mistake 3 — Manually deleting a pointer already owned by a smart pointer

cpp

#include <memory>

int main() {
    int* raw = new int(5);
    std::unique_ptr<int> p(raw);

    // delete raw;   // never do this — p will delete it again in its destructor
    //               // double-delete is undefined behavior
}

Once a raw pointer is handed to a smart pointer, treat the raw pointer as if it does not exist.

Quick Reference

Resource	RAII type	Acquired	Released
Heap memory (sole owner)	`std::unique_ptr<T>`	`make_unique<T>(...)`	destructor calls `delete`
Heap memory (shared)	`std::shared_ptr<T>`	`make_shared<T>(...)`	last destructor calls `delete`
Mutex	`std::lock_guard<M>`	constructor locks	destructor unlocks
File stream	`std::ifstream` / `std::ofstream`	constructor opens	destructor closes
Any other resource	write your own class	constructor acquires	destructor releases

Rules to keep close:

Acquire in the constructor, release in the destructor.
Delete the copy constructor and copy assignment in any class that uniquely owns a resource.
Prefer std::make_unique over new. Prefer std::make_shared over new.
Never manually delete a pointer that a smart pointer already owns.

What's Next

RAII — deep dive — the full reference with advanced patterns and custom deleters
Smart pointers — unique_ptr, shared_ptr, and weak_ptr compared side by side
Move semantics — how RAII objects transfer ownership efficiently without copying
Constructors and destructors — the lifetime mechanics that make RAII possible

Exception Safety and RAII

RAII is the only reliable cleanup mechanism when C++ exceptions are enabled. When an exception is thrown, C++ unwinds the call stack, destroying every local object in reverse construction order. If your resources are tied to those local objects through RAII, cleanup happens automatically. If they are not — if you rely on explicit delete or fclose calls at the end of a function — those calls are simply skipped.

Consider the difference:

cpp

#include <memory>
#include <fstream>
#include <stdexcept>

void process_without_raii() {
    int* buf = new int[1024];
    std::FILE* f = std::fopen("data.bin", "rb");

    // If this throws, buf and f are both leaked.
    might_throw();

    std::fclose(f);
    delete[] buf;      // never reached if might_throw() fires
}

void process_with_raii() {
    auto buf = std::make_unique<int[]>(1024);
    std::ifstream f("data.bin", std::ios::binary);

    might_throw();     // exception unwinds the stack — destructors run
    // buf deleted, f.close() called — zero leaks, zero effort
}

C++ defines four levels of exception safety. RAII gets you to the strong guarantee (the operation either succeeds completely or leaves everything unchanged) almost for free, because destructors run in a predictable, deterministic order during stack unwinding. Languages without deterministic destructors cannot offer this guarantee without extra framework support.

The Scope Guard Idiom

A scope guard is a generic RAII wrapper that runs an arbitrary cleanup action when it goes out of scope, without you needing to write a dedicated class. It is useful when you have a one-off cleanup that does not justify a full RAII class — for example, resetting a flag, decrementing a counter, or rolling back a partial operation.

Here is a minimal implementation using a lambda and a template:

cpp

#include <iostream>
#include <utility>

template <typename F>
class ScopeGuard {
public:
    explicit ScopeGuard(F fn) : fn_(std::move(fn)), active_(true) {}

    ~ScopeGuard() { if (active_) fn_(); }

    // Allow caller to cancel the guard (e.g., on success).
    void dismiss() { active_ = false; }

    ScopeGuard(const ScopeGuard&)            = delete;
    ScopeGuard& operator=(const ScopeGuard&) = delete;

private:
    F    fn_;
    bool active_;
};

// Deduction guide (C++17) — lets you write ScopeGuard guard{...}
template <typename F>
ScopeGuard(F) -> ScopeGuard<F>;

void register_and_maybe_fail(bool should_fail) {
    // Imagine we registered something that needs un-registering on failure.
    std::cout << "registered\n";

    ScopeGuard rollback{[&] {
        std::cout << "unregistered (rollback)\n";
    }};

    if (should_fail) {
        throw std::runtime_error("something went wrong");
    }

    rollback.dismiss();   // success — cancel the cleanup
    std::cout << "committed\n";
}

int main() {
    try { register_and_maybe_fail(true);  } catch (...) {}
    try { register_and_maybe_fail(false); } catch (...) {}
}

Output:

cpp

registered
unregistered (rollback)
registered
committed

Many production codebases carry a utility like this. The C++ standard does not include one directly, but some libraries (Abseil, Folly, GSL) provide similar helpers under names like absl::Cleanup or gsl::finally.

Rule of Five Recap

If you write a custom destructor for a class that owns a resource, you almost certainly need to write or explicitly delete the copy constructor, copy assignment operator, move constructor, and move assignment operator as well. This is the Rule of Five (an extension of the older Rule of Three, updated for C++11 move semantics).

The reason: the compiler-generated copy operations do a shallow copy of member variables. For a class that holds a raw pointer to heap memory, that means two objects end up pointing to the same allocation — and both will try to free it when they are destroyed.

cpp

#include <cstring>
#include <utility>
#include <iostream>

class Buffer {
public:
    explicit Buffer(std::size_t n)
        : data_(new char[n]), size_(n)
    { std::memset(data_, 0, n); }

    ~Buffer() { delete[] data_; }

    // Copy constructor — deep copy
    Buffer(const Buffer& other)
        : data_(new char[other.size_]), size_(other.size_)
    { std::memcpy(data_, other.data_, size_); }

    // Copy assignment — copy-and-swap for strong exception safety
    Buffer& operator=(Buffer other) {
        std::swap(data_, other.data_);
        std::swap(size_, other.size_);
        return *this;
    }

    // Move constructor — steal the pointer
    Buffer(Buffer&& other) noexcept
        : data_(other.data_), size_(other.size_)
    { other.data_ = nullptr; other.size_ = 0; }

    // Move assignment
    Buffer& operator=(Buffer&& other) noexcept {
        if (this != &other) {
            delete[] data_;
            data_       = other.data_;
            size_       = other.size_;
            other.data_ = nullptr;
            other.size_ = 0;
        }
        return *this;
    }

    std::size_t size() const { return size_; }

private:
    char*       data_;
    std::size_t size_;
};

int main() {
    Buffer a(64);
    Buffer b = a;              // deep copy — separate allocation
    Buffer c = std::move(a);   // move — a is now empty
    std::cout << b.size() << " " << c.size() << "\n";  // 64 64
}

Alternatively, store the resource in a unique_ptr member and let the compiler delete the copy operations for you automatically — that is the preferred modern approach when you do not need copying.

RAII for Non-Memory Resources

RAII applies to every resource that must be released, not just heap memory. File handles, mutex locks, network sockets, database connections, GPU command buffers, and shared memory segments are all resources. The pattern is always the same: acquire in the constructor, release in the destructor.

cpp

#include <mutex>
#include <iostream>
#include <stdexcept>

// RAII mutex wrapper (std::lock_guard already does this — shown for clarity).
class MutexLock {
public:
    explicit MutexLock(std::mutex& m) : mutex_(m) { mutex_.lock(); }
    ~MutexLock() { mutex_.unlock(); }
    MutexLock(const MutexLock&) = delete;
    MutexLock& operator=(const MutexLock&) = delete;
private:
    std::mutex& mutex_;
};

// RAII wrapper for a network socket file descriptor.
class Socket {
public:
    explicit Socket(int fd) : fd_(fd) {
        if (fd_ < 0) throw std::runtime_error("invalid socket");
        std::cout << "socket " << fd_ << " opened\n";
    }
    ~Socket() {
        if (fd_ >= 0) {
            // ::close(fd_);  // real code calls the system close()
            std::cout << "socket " << fd_ << " closed\n";
        }
    }
    Socket(const Socket&) = delete;
    Socket& operator=(const Socket&) = delete;
    int fd() const { return fd_; }
private:
    int fd_;
};

int main() {
    std::mutex mtx;
    {
        MutexLock lock(mtx);       // locked
        Socket    sock(3);         // "opened"
        // use sock...
    }   // sock destroyed first (closed), then lock released — always
}

Output:

cpp

socket 3 opened
socket 3 closed

The same approach extends to GPU resources (e.g., wrapping vkCreateCommandPool/vkDestroyCommandPool in Vulkan), shared memory segments (mmap/munmap), and any OS handle that has a paired open/close API.

Anti-Patterns to Avoid

Certain coding habits defeat RAII and reintroduce the resource-leak bugs it is designed to eliminate. Recognising these patterns lets you catch them in code review and in your own code.

Naked `new` without an immediate owner

cpp

// WRONG — if something between new and the manual delete throws,
// the memory is leaked.
void bad_alloc() {
    Foo* p = new Foo();
    do_something_risky();   // may throw
    delete p;               // skipped on exception
}

// RIGHT — unique_ptr owns the allocation immediately.
void good_alloc() {
    auto p = std::make_unique<Foo>();
    do_something_risky();   // exception unwinds — p cleaned up
}

Raw `fopen`/`fclose` without a wrapper

cpp

// WRONG
void bad_file() {
    FILE* f = std::fopen("data.csv", "r");
    parse(f);       // if parse() throws, f is never closed
    std::fclose(f);
}

// RIGHT — use std::ifstream (RAII) or your own FileHandle wrapper.
#include <fstream>
void good_file() {
    std::ifstream f("data.csv");
    parse(f);       // exception unwinds — f.~ifstream() closes the file
}

Manually managing a mutex without a guard

cpp

#include <mutex>
std::mutex g_mtx;

// WRONG — unlock is skipped if an exception occurs between lock and unlock.
void bad_lock() {
    g_mtx.lock();
    risky_work();
    g_mtx.unlock();
}

// RIGHT
void good_lock() {
    std::lock_guard<std::mutex> guard(g_mtx);
    risky_work();
}   // guard destructor unlocks — always

The pattern is the same in every case: replace a pair of matched API calls with a RAII type whose constructor does the first call and whose destructor does the second.

Real-World Example: RAII Database Transaction

A database transaction is a textbook RAII use case: you want to commit on success and roll back automatically on any failure, including exceptions. Wrapping the transaction in an RAII class makes the commit/rollback logic impossible to forget.

cpp

#include <iostream>
#include <stdexcept>
#include <string>

// Simulate a minimal DB connection interface.
struct DbConnection {
    void execute(const std::string& sql) {
        std::cout << "SQL: " << sql << "\n";
    }
};

class Transaction {
public:
    explicit Transaction(DbConnection& db) : db_(db), committed_(false) {
        db_.execute("BEGIN");
    }

    ~Transaction() {
        if (!committed_) {
            db_.execute("ROLLBACK");  // automatic on any exit path
        }
    }

    void commit() {
        db_.execute("COMMIT");
        committed_ = true;
    }

    Transaction(const Transaction&)            = delete;
    Transaction& operator=(const Transaction&) = delete;

private:
    DbConnection& db_;
    bool          committed_;
};

void transfer_funds(DbConnection& db, int from_id, int to_id, int amount) {
    Transaction tx(db);   // BEGIN

    db.execute("UPDATE accounts SET balance = balance - " +
               std::to_string(amount) + " WHERE id = " + std::to_string(from_id));

    if (amount > 1000) {
        throw std::runtime_error("amount exceeds daily limit");  // triggers ROLLBACK
    }

    db.execute("UPDATE accounts SET balance = balance + " +
               std::to_string(amount) + " WHERE id = " + std::to_string(to_id));

    tx.commit();   // COMMIT only on full success
}

int main() {
    DbConnection db;

    std::cout << "--- Transfer 500 (should commit) ---\n";
    try { transfer_funds(db, 1, 2, 500); } catch (const std::exception& e) {
        std::cout << "Error: " << e.what() << "\n";
    }

    std::cout << "\n--- Transfer 2000 (should rollback) ---\n";
    try { transfer_funds(db, 1, 2, 2000); } catch (const std::exception& e) {
        std::cout << "Error: " << e.what() << "\n";
    }
}

Output:

cpp

--- Transfer 500 (should commit) ---
SQL: BEGIN
SQL: UPDATE accounts SET balance = balance - 500 WHERE id = 1
SQL: UPDATE accounts SET balance = balance + 500 WHERE id = 2
SQL: COMMIT

--- Transfer 2000 (should rollback) ---
SQL: BEGIN
SQL: UPDATE accounts SET balance = balance - 2000 WHERE id = 1
Error: amount exceeds daily limit
SQL: ROLLBACK

The destructor guarantees the rollback fires even when an exception propagates through multiple call-stack frames — something that is nearly impossible to guarantee with manual try/catch/rollback logic once the call graph becomes complex.

Testing RAII Classes

Verifying that a RAII class cleans up correctly requires testing both the happy path and the exception path. The exception path is the one most likely to be broken, and it is the one that manual cleanup code always forgets to cover.

A lightweight pattern uses a mock that records whether cleanup was called:

cpp

#include <iostream>
#include <stdexcept>
#include <cassert>

// Tracks whether the resource was released.
struct MockResource {
    bool& released;
    explicit MockResource(bool& flag) : released(flag) { released = false; }
};

// RAII wrapper under test.
class Holder {
public:
    explicit Holder(MockResource& r) : resource_(&r) {}
    ~Holder() { resource_->released = true; }

    Holder(const Holder&) = delete;
    Holder& operator=(const Holder&) = delete;

private:
    MockResource* resource_;
};

// Helper: runs fn, catches any exception, returns whether cleanup happened.
template <typename Fn>
bool cleanup_happened(bool& flag, Fn fn) {
    flag = false;
    try { fn(); } catch (...) {}
    return flag;
}

int main() {
    bool released = false;
    MockResource res(released);

    // Happy path: destructor should run at end of lambda scope.
    bool ok = cleanup_happened(released, [&] {
        Holder h(res);
        // normal work — no exception
    });
    assert(ok && "cleanup must run on normal exit");
    std::cout << "happy path: PASS\n";

    // Exception path: destructor must still run during stack unwinding.
    bool exc_ok = cleanup_happened(released, [&] {
        Holder h(res);
        throw std::runtime_error("simulated failure");
    });
    assert(exc_ok && "cleanup must run when exception is thrown");
    std::cout << "exception path: PASS\n";
}

Output:

cpp

happy path: PASS
exception path: PASS

For production code, the same technique works with Google Test or Catch2 — replace assert with EXPECT_TRUE or REQUIRE. The important principle is that both paths must be tested explicitly, because an RAII class that leaks on exceptions provides no safety guarantee at all.

Understand and Use Pointers in C++Understand and Use References in C++