RAII as a Pattern

Part of the Object Oriented Programming section of Coddy's C++ journey — lesson 102 of 104.

RAII (Resource Acquisition Is Initialization) is more than just a C++ idiom - it's a powerful design pattern that ties resource management to object lifetime. You've already seen RAII with smart pointers, but the pattern applies to any resource: file handles, network connections, mutexes, or database transactions.

The core idea is simple: acquire resources in the constructor, release them in the destructor. Since C++ guarantees destructors run when objects go out of scope, cleanup happens automatically - even when exceptions occur:

#include <iostream>
#include <fstream>

class FileGuard {
    std::ofstream file;
public:
    FileGuard(const std::string& filename) : file(filename) {
        if (!file.is_open()) {
            std::cout << "Failed to open file\n";
        }
    }
    
    void write(const std::string& text) {
        if (file.is_open()) file << text;
    }
    
    ~FileGuard() {
        if (file.is_open()) {
            file.close();
            std::cout << "File closed automatically\n";
        }
    }
};

int main() {
    {
        FileGuard guard("output.txt");
        guard.write("Hello RAII");
    }  // Destructor called here - file closed
    
    std::cout << "After scope\n";
}

RAII shines when managing locks in multithreaded code. The standard library's std::lock_guard follows this pattern - it acquires a mutex on construction and releases it on destruction, preventing deadlocks from forgotten unlocks.

When implementing RAII classes, remember to either delete or properly implement copy/move operations (Rule of Five) to prevent resource duplication or double-release issues. RAII transforms error-prone manual resource management into safe, automatic cleanup.

Challenge

Easy

Let's build a Connection Pool Manager using RAII to safely manage database connections. In real applications, database connections are expensive resources that must be properly acquired and released. You'll create an RAII wrapper that guarantees connections are always returned to the pool, even if exceptions occur or code paths get complicated.

You'll organize your code across three files:

ConnectionPool.h: Create a simple connection pool that manages a limited number of connections.
Your ConnectionPool class should track how many connections are available (start with a capacity passed to the constructor). Implement:
- acquire() — if a connection is available, decrease the count and print Connection acquired (X available) where X is the remaining count; return true if successful, false if no connections available
- release() — increase the available count and print Connection released (X available)
- available() — returns the current number of available connections
ConnectionGuard.h: Build the RAII wrapper that safely manages a single connection.
Your ConnectionGuard class embodies the RAII pattern. It should:
- Take a reference to a ConnectionPool in its constructor and attempt to acquire a connection
- Store whether the acquisition was successful
- Provide an isConnected() method to check if the guard holds a valid connection
- Automatically release the connection back to the pool in the destructor (only if one was acquired)
- Delete copy constructor and copy assignment to prevent resource duplication (Rule of Five consideration)
When the destructor runs, if a connection was held, print Guard releasing connection before calling release on the pool.
main.cpp: Demonstrate RAII's automatic cleanup through scopes.
Read two inputs:
1. Pool capacity (integer)
2. Number of connections to request (integer)
Create a ConnectionPool with the given capacity. Then, inside a nested scope (using curly braces), create the requested number of ConnectionGuard objects stored in a vector. For each guard, print whether it connected successfully:
- If connected: Guard N: Connected
- If not connected: Guard N: Failed to connect
(where N starts at 1)

After the scope ends (guards are destroyed), print After scope: X connections available showing the pool's final state.

For example, with inputs 2 and 3:

Connection acquired (1 available)
Guard 1: Connected
Connection acquired (0 available)
Guard 2: Connected
Guard 3: Failed to connect
Guard releasing connection
Connection released (1 available)
Guard releasing connection
Connection released (2 available)
After scope: 2 connections available

With inputs 3 and 2:

Connection acquired (2 available)
Guard 1: Connected
Connection acquired (1 available)
Guard 2: Connected
Guard releasing connection
Connection released (2 available)
Guard releasing connection
Connection released (3 available)
After scope: 3 connections available

Notice how the connections are automatically released when the guards go out of scope—you never explicitly call release in your main code. The destructors run in reverse order of construction (last guard destroyed first), and every acquired connection is guaranteed to be returned. This is the power of RAII: resource cleanup happens automatically and reliably, no matter how the scope exits.

Cheat sheet

RAII (Resource Acquisition Is Initialization) is a design pattern that ties resource management to object lifetime. Resources are acquired in the constructor and released in the destructor.

Since C++ guarantees destructors run when objects go out of scope, cleanup happens automatically—even when exceptions occur:

class FileGuard {
    std::ofstream file;
public:
    FileGuard(const std::string& filename) : file(filename) {
        if (!file.is_open()) {
            std::cout << "Failed to open file\n";
        }
    }
    
    void write(const std::string& text) {
        if (file.is_open()) file << text;
    }
    
    ~FileGuard() {
        if (file.is_open()) {
            file.close();
            std::cout << "File closed automatically\n";
        }
    }
};

int main() {
    {
        FileGuard guard("output.txt");
        guard.write("Hello RAII");
    }  // Destructor called here - file closed automatically
    
    std::cout << "After scope\n";
}

RAII is particularly useful for managing locks in multithreaded code. The standard library's std::lock_guard acquires a mutex on construction and releases it on destruction, preventing deadlocks from forgotten unlocks.

When implementing RAII classes, delete or properly implement copy/move operations (Rule of Five) to prevent resource duplication or double-release issues.

Try it yourself

#include <iostream>
#include <vector>
#include "ConnectionPool.h"
#include "ConnectionGuard.h"

using namespace std;

int main() {
    // Read inputs
    int capacity;
    int numConnections;
    cin >> capacity;
    cin >> numConnections;
    
    // TODO: Create a ConnectionPool with the given capacity
    
    // TODO: Create a nested scope using curly braces
    {
        // TODO: Create a vector to store ConnectionGuard objects
        // Hint: You'll need to use pointers or smart pointers since ConnectionGuard
        // has deleted copy constructor
        
        // TODO: Loop to create numConnections guards
        // For each guard, print either:
        // "Guard N: Connected" or "Guard N: Failed to connect"
        // where N starts at 1
        
    }
    // Guards are destroyed here when scope ends
    
    // TODO: Print "After scope: X connections available"
    
    return 0;
}