Gestión de recursos: Regla de tres, cinco y cero

Cuando diseñas una clase que gestiona un recurso de forma manual (como un puntero a memoria en el heap, un descriptor de archivo o un socket), la vida de ese objeto queda ligada a la gestión de ese recurso. La Regla de Tres [C++98] establece que si necesitas definir un destructor personalizado para liberar ese recurso, casi con seguridad también necesitarás un constructor de copia y un operador de asignación por copia. Esto sucede porque, por defecto, el compilador realiza una copia superficial (shallow copy), copiando los punteros pero no la memoria a la que apuntan. Si dos objetos comparten el mismo puntero, ambos intentarán liberarlo al destruirse, provocando un error de doble liberación (double free).

Con la llegada de C++11 y la introducción de las rvalue references, la gestión de recursos evolucionó hacia la Regla de Cinco. Si tu clase gestiona recursos y defines los métodos anteriores, también debes implementar el constructor de movimiento y el operador de asignación por movimiento para aprovechar la semántica de movimiento. Sin estos, los objetos temporales se copiarán innecesariamente, perdiendo la eficiencia de transferencia de propiedad que permite evitar asignaciones costosas en el heap.

Sin embargo, la arquitectura moderna de C++ aboga por la Regla de Cero. Esta consiste en diseñar tus clases de modo que no tengan que gestionar recursos manualmente, delegando esa responsabilidad en miembros que ya implementen correctamente el RAII (Resource Acquisition Is Initialization), como std::vector, std::string o std::unique_ptr. Si sigues la Regla de Cero, no necesitas definir ninguno de los cinco métodos especiales; el compilador generará versiones por defecto que funcionan exactamente como esperas. Esta es la estrategia preferida siempre que sea posible, ya que reduce drásticamente la superficie de errores y la complejidad del código.

La excepción ocurre cuando estás construyendo las bases de la infraestructura, como un contenedor personalizado o un puntero inteligente propio. En esos casos, la Regla de Cinco es obligatoria.

#include <iostream>
#include <vector>
#include <algorithm>
#include <utility>
#include <type_traits>

// Caso de uso de la Regla de Cinco: Gestión manual de un buffer
class ManualBuffer {
private:
    int* data_;
    size_t size_;

public:
    // Constructor
    explicit ManualBuffer(size_t size) : size_(size), data_(new int[size]()) {}

    // 1. Destructor (Necesario por el puntero raw)
    ~ManualBuffer() {
        delete[] data_;
    }

    // 2. Constructor de copia (Deep copy)
    ManualBuffer(const ManualBuffer& other) : size_(other.size_), data_(new int[other.size_]) {
        std::copy(other.data_, other.data_ + other.size_, data_);
    }

    // 3. Operador de asignación por copia (Copy-and-swap idiom)
    ManualBuffer& operator=(const ManualBuffer& other) {
        if (this != &other) {
            // Creamos una copia temporal para garantizar seguridad ante excepciones
            ManualBuffer temp(other);
            swap(temp);
        }
        return *this;
    }

    // 4. Constructor de movimiento (Transferencia de propiedad)
    ManualBuffer(ManualBuffer&& other) noexcept : data_(nullptr), size_(0) {
        swap(other);
    }

    // 5. Operador de asignación por movimiento
    ManualBuffer& operator=(ManualBuffer&& other) noexcept {
        swap(other);
        return *this;
    }

    void swap(ManualBuffer& other) noexcept {
        using std::swap;
        swap(data_, other.data_);
        swap(size_, other.size_);
    }

    void print() const {
        if (!data_) {
            std::cout << "Buffer vacío\n";
            return;
        }
        for (size_t i = 0; i < size_; ++i) std::cout << data_[i] << " ";
        std::cout << "\n";
    }
};

// Caso de uso de la Regla de Cero: Delegación en tipos RAII
class ModernBuffer {
private:
    std::vector<int> data_; // std::vector ya implementa las 5 reglas correctamente

public:
    explicit ModernBuffer(size_t size) : data_(size, 0) {}

    // No definimos destructor, ni copy/move constr/assign. 
    // El compilador lo hace por nosotros.

    void print() const {
        for (int val : data_) std::cout << val << " ";
        std::cout << "\n";
    }
};

int main() {
    // Demostración de ManualBuffer (Regla de Cinco)
    std::cout << "--- ManualBuffer (Regla de Cinco) ---\n";
    ManualBuffer m1(3);
    m1.print();

    ManualBuffer m2 = m1; // Llama al constructor de copia
    std::cout << "m2 (copia de m1): ";
    m2.print();

    ManualBuffer m3 = std::move(m1); // Llama al constructor de movimiento
    std::cout << "m3 (movida desde m1): ";
    m3.print();
    std::cout << "m1 (tras el movimiento): ";
    m1.print();

    // Demostración de ModernBuffer (Regla de Cero)
    std::cout << "\n--- ModernBuffer (Regla de Cero) ---\n";
    ModernBuffer mod1(3);
    ModernBuffer mod2 = mod1; // Copia segura automática
    ModernBuffer mod3 = std::move(mod1); // Movimiento eficiente automático
    
    std::cout << "mod2 (copia): ";
    mod2.print();
    std::cout << "mod3 (movida): ";
    mod3.print();

    // Verificación de propiedades en tiempo de compilación
    static_assert(std::is_move_constructible_v<ManualBuffer>, "ManualBuffer debe ser movible");
    static_assert(std::is_trivially_copyable_v<std::vector<int>>, "vector es trivialmente copiable");

    return 0;
}

Desglose del ejemplo

En ManualBuffer, hemos implementado la Regla de Cinco para garantizar que la gestión de la memoria sea correcta.

1. El destructor ~ManualBuffer() es esencial para evitar fugas de memoria (memory leaks) al liberar el puntero data_.
2. El constructor de copia realiza una “copia profunda”: reserva nueva memoria y copia los valores. Sin esto, m2 en el main apuntaría a la misma dirección de memoria que m1.
3. El operador de asignación utiliza el idiom copy-and-swap. Esto no solo es robusto ante excepciones, sino que permite reutilizar la lógica de copia y movimiento.
4. El constructor de movimiento ManualBuffer(ManualBuffer&& other) es noexcept. Esto es crítico para que los contenedores como std::vector puedan mover objetos en lugar de copiarlos durante una reasignación de capacidad.
5. En ModernBuffer, aplicamos la Regla de Cero. Al usar std::vector<int>, no necesitamos declarar nada. El compilador genera un destructor que libera el vector, un constructor de copia que copia el vector y un constructor de movimiento que mueve el vector.

Para verificar esto en tiempo de compilación, usamos std::is_move_constructible_v, que confirma que el compilador sabe cómo mover la clase, y std::is_trivially_copyable_v para ver si una clase puede copiarse mediante una simple copia de bytes (como ocurre con los tipos POD o la mayoría de los tipos de la STL).

El error frecuente

El error más peligroso en C++ es ignorar la Regla de Tres/Cinco cuando usas punteros crudos. Si defines un destructor pero olvidas el constructor de copia, el compilador usará el constructor por defecto que realiza una copia superficial:

// ERROR: Falta el constructor de copia
class Broken {
    int* data;
public:
    Broken() : data(new int(42)) {}
    ~Broken() { delete data; }
};

// En el main:
{
    Broken b1;
    Broken b2 = b1; // Error: b1.data y b2.data apuntan a la misma dirección
} // ERROR: Se llama al destructor de b2 (libera la memoria) y luego el de b1.
  // Esto causa un CRASH por "double free detected".

Este error suele pasar desapercibido durante el desarrollo y solo estalla en producción o cuando se activan los sanitizadores de memoria. Para detectarlo, compila siempre con AddressSanitizer usando -fsanitize=address.

N° 40