Implementación de RAII para recursos personalizados

El patrón RAII (Resource Acquisition Is Initialization) consiste en vincular el ciclo de vida de un recurso (un descriptor de archivo, un semáforo, una conexión de red o un bloque de memoria de un driver) al ciclo de vida de un objeto con almacenamiento en el stack (pila). El mecanismo fundamental es la garantía del lenguaje C++ de que, cuando un objeto local sale de su scope (alcance), su destructor es invocado automáticamente, ya sea que el flujo termine mediante un return o debido a una excepción lanzada.

Esto resuelve el problema de la gestión manual de recursos donde un close() o free() olvidado tras una excepción provoca una fuga de recursos (resource leak). Para implementar RAII en recursos propios, debemos seguir la regla de los cinco [C++11], pero con una distinción semántica vital: la propiedad única (unique ownership). Dado que un recurso físico no puede ser “duplicado” (no puedes tener dos objetos intentando cerrar el mismo socket), debemos marcar el constructor de copia y el operador de asignación de copia como delete. Para permitir la transferencia de la gestión del recurso, implementamos la semántica de movimiento (move semantics), transfiriendo el puntero o el handle del objeto origen al destino y dejando al origen en un estado válido pero nulo.

Este patrón es indispensable cuando trabajas con APIs de C o hardware donde la gestión de errores no es nativa. Si implementas mal la transferencia de propiedad (por ejemplo, olvidando anular el puntero en el objeto origen), causarás un double-free o un use-after-free, errores que suelen manifestarse como corrupción de memoria catastrófica en producción.

#include <iostream>
#include <utility>
#include <functional>
#include <memory>
#include <stdexcept>

// Simulación de una API de C legacy para un recurso de hardware
struct RawHardwareHandle {
    int id;
    bool is_open = false;
};

void hardware_api_open(RawHardwareHandle* h, int id) {
    h->id = id;
    h->is_open = true;
    std::cout << "  [API] Hardware " << id << " abierto.\n";
}

void hardware_api_close(RawHardwareHandle* h) {
    if (h && h->is_open) {
        std::cout << "  [API] Hardware " << h->id << " cerrado.\n";
        h->is_open = false;
    }
}

// Clase RAII para gestionar el recurso de hardware
class HardwareDevice {
    RawHardwareHandle* handle = nullptr;

public:
    explicit HardwareDevice(int id) : handle(new RawHardwareHandle()) {
        hardware_api_open(handle, id);
    }

    // Destructor: la pieza clave de RAII
    ~HardwareDevice() {
        if (handle) {
            hardware_api_close(handle);
            delete handle;
        }
    }

    // Prohibimos copias: un recurso físico no se puede duplicar
    HardwareDevice(const HardwareDevice&) = delete;
    HardwareDevice& operator=(const HardwareDevice&) = delete;

    // Permitimos movimientos: transferimos la propiedad (ownership)
    HardwareDevice(HardwareDevice&& other) noexcept : handle(other.handle) {
        other.handle = nullptr; // El origen queda vacío
    }

    HardwareDevice& operator=(HardwareDevice&& other) noexcept {
        if (this != &other) {
            // Liberamos nuestro recurso actual antes de tomar el nuevo
            if (handle) {
                hardware_api_close(handle);
                delete handle;
            }
            handle = other.handle;
            other.handle = nullptr;
        }
        return *this;
    }

    void use() const {
        if (handle && handle->is_open) {
            std::cout << "  [Device] Usando hardware " << handle->id << "\n";
        }
    }
};

// Técnica "Scope Guard" para código legacy donde no puedes crear una clase nueva
struct ScopeExit {
    std::function<void()> action;
    ~ScopeExit() { if (action) action(); }
};

int main() {
    // 1. Uso estándar de RAII
    {
        std::cout << "--- Escenario 1: RAII estándar ---\n";
        HardwareDevice dev(101);
        dev.use();
    } // Aquí se llama al destructor y se cierra el hardware automáticamente

    // 2. Transferencia de propiedad (Move Semantics)
    {
        std::cout << "\n--- Escenario 2: Movimiento ---\n";
        HardwareDevice dev1(202);
        HardwareDevice dev2 = std::move(dev1); // dev1 queda vacío, dev2 es el dueño
        dev2.use();
    }

    // 3. Scope Guard para limpieza rápida en bloques específicos
    {
        std::cout << "\n--- Escenario 3: Scope Guard ---\n";
        bool log_done = false;
        {
            ScopeExit guard{ [&]() { 
                std::cout << "  [Guard] Limpieza de logs local.\n"; 
            }};
            std::cout << "  [Main] Realizando operaciones críticas...\n";
            log_done = true;
        } 
    }

    // 4. std::unique_ptr con deleter personalizado (La forma moderna para handles simples)
    {
        std::cout << "\n--- Escenario 4: std::unique_ptr con deleter ---\n";
        // Usamos un deleter lambda para manejar el cierre del handle de C
        std::unique_ptr<RawHardwareHandle, void(*)(RawHardwareHandle*)> smart_handle(
            new RawHardwareHandle(),
            [](RawHardwareHandle* h) {
                std::cout << "  [unique_ptr] Liberando handle de C.\n";
                delete h;
            }
        );
        hardware_api_open(smart_handle.get(), 303);
    }

    return 0;
}

Desglose del ejemplo

En el código anterior, HardwareDevice encapsula la gestión de un RawHardwareHandle.

1. Gestión de ciclo de vida: En el primer bloque de main(), dev es un objeto en el stack. Al llegar a la llave de cierre }, el compilador garantiza la llamada a ~HardwareDevice(), lo que desencadena hardware_api_close. Esto proporciona la garantía fuerte de excepción: si algo fallara antes del cierre, el recurso se liberaría igual.
2. Semántica de movimiento: En el Escenario 2, HardwareDevice dev2 = std::move(dev1); invoca el constructor de movimiento. Fíjate en la asignación other.handle = nullptr;. Esto es crítico: si no anularas el puntero en dev1, cuando dev1 saliera de su scope, intentaría liberar la misma memoria que dev2 ya está gestionando, provocando un crash por double-free.
3. Scope Guard: El ScopeExit utiliza un objeto local para ejecutar una lambda en su destructor. Es una técnica de “emergencia” muy útil cuando integras código de librerías de terceros que no siguen RAII y no quieres/puedes envolverlos en una clase completa.
4. Deleters personalizados: En el Escenario 4, aprovechamos std::unique_ptr. En lugar de crear una clase envolvente completa, le pasamos un deleter (una función o lambda) al template. Esto es la forma más eficiente y estándar de manejar punteros a estructuras de C (como FILE* o SSL*) sin el overhead de una clase extra.

El error frecuente

Un error clásico al implementar el operador de asignación de movimiento es olvidar liberar el recurso que el objeto ya poseía antes de tomar el nuevo.

// ERROR: Fuga de recursos (Resource Leak)
HardwareDevice& operator=(HardwareDevice&& other) noexcept {
    if (this != &other) {
        // Si este objeto ya tenía un 'handle' abierto, lo perdemos 
        // sin cerrarlo porque no llamamos a hardware_api_close.
        handle = other.handle; 
        other.handle = nullptr;
    }
    return *this;
}

Si ejecutas este código, el objeto original perderá su conexión al hardware sin cerrarla, dejando el dispositivo en un estado de uso bloqueado o consumiendo recursos del sistema hasta que el proceso termine. Siempre, en un operador de asignación, debes asegurar que el objeto actual esté en un estado “limpio” antes de absorber la nueva propiedad.

N° 145