¿Qué es el modismo de copiar e intercambiar?

Descripción general

¿Por qué necesitamos el modismo de copiar e intercambiar?

Cualquier clase que administre un recurso (un contenedor , como un puntero inteligente) necesita implementar Los Tres Grandes . Si bien los objetivos y la implementación del constructor de copias y del destructor son sencillos, se puede decir que el operador de asignación de copias es el más matizado y difícil. ¿Cómo deberia hacerse? ¿Qué trampas hay que evitar?

El modismo copiar e intercambiar es la solución y ayuda elegantemente al operador de asignación a lograr dos cosas: evitar la duplicación de código y proporcionar una sólida garantía de excepción .

¿Como funciona?

Conceptualmente , funciona utilizando la funcionalidad del constructor de copias para crear una copia local de los datos, luego toma los datos copiados con una swapfunción, intercambiando los datos antiguos con los nuevos. La copia temporal luego se destruye, llevándose consigo los datos antiguos. Nos quedamos con una copia de los nuevos datos.

Para usar el modismo de copiar e intercambiar, necesitamos tres cosas: un constructor de copia que funcione, un destructor que funcione (ambos son la base de cualquier contenedor, por lo que deberían estar completos de todos modos) y una swapfunción.

Una función de intercambio es una función que no lanza y que intercambia dos objetos de una clase, miembro por miembro. Podríamos sentirnos tentados a utilizar std::swaplos nuestros en lugar de proporcionarlos, pero esto sería imposible; std::swaputiliza el constructor de copia y el operador de asignación de copia dentro de su implementación y, en última instancia, estaríamos tratando de definir el operador de asignación en términos de sí mismo.

(No solo eso, sino que las llamadas no calificadas utilizarán swapnuestro operador de intercambio personalizado, omitiendo la construcción y destrucción innecesaria de nuestra clase que std::swapimplicaría).

Una explicación en profundidad

La meta

Consideremos un caso concreto. Queremos gestionar, en una clase que de otro modo sería inútil, una matriz dinámica. Comenzamos con un constructor, un constructor de copias y un destructor en funcionamiento:

#include <algorithm> // std::copy
#include <cstddef> // std::size_t

class dumb_array
{
public:
    // (default) constructor
    dumb_array(std::size_t size = 0)
        : mSize(size),
          mArray(mSize ? new int[mSize]() : nullptr)
    {
    }

    // copy-constructor
    dumb_array(const dumb_array& other)
        : mSize(other.mSize),
          mArray(mSize ? new int[mSize] : nullptr)
    {
        // note that this is non-throwing, because of the data
        // types being used; more attention to detail with regards
        // to exceptions must be given in a more general case, however
        std::copy(other.mArray, other.mArray + mSize, mArray);
    }

    // destructor
    ~dumb_array()
    {
        delete [] mArray;
    }

private:
    std::size_t mSize;
    int* mArray;
};

Esta clase casi administra la matriz con éxito, pero debe operator=funcionar correctamente.

Una solución fallida

Así es como podría verse una implementación ingenua:

// the hard part
dumb_array& operator=(const dumb_array& other)
{
    if (this != &other) // (1)
    {
        // get rid of the old data...
        delete [] mArray; // (2)
        mArray = nullptr; // (2) *(see footnote for rationale)

        // ...and put in the new
        mSize = other.mSize; // (3)
        mArray = mSize ? new int[mSize] : nullptr; // (3)
        std::copy(other.mArray, other.mArray + mSize, mArray); // (3)
    }

    return *this;
}

Y decimos que hemos terminado; esto ahora gestiona una matriz, sin fugas. Sin embargo, sufre tres problemas, marcados secuencialmente en el código como (n).

1. La primera es la prueba de autoasignación.
   Esta verificación tiene dos propósitos: es una manera fácil de evitar que ejecutemos código innecesario en la autoasignación y nos protege de errores sutiles (como eliminar la matriz solo para intentar copiarla). Pero en todos los demás casos simplemente sirve para ralentizar el programa y actuar como ruido en el código; La autoasignación rara vez ocurre, por lo que la mayoría de las veces esta verificación es un desperdicio.
   Sería mejor si el operador pudiera trabajar correctamente sin él.

2. La segunda es que solo proporciona una garantía de excepción básica. Si new int[mSize]falla, *thisse habrá modificado. (Es decir, ¡el tamaño es incorrecto y los datos desaparecieron!)
   Para una garantía de excepción sólida, tendría que ser algo parecido a:

    dumb_array& operator=(const dumb_array& other)
    {
        if (this != &other) // (1)
        {
            // get the new data ready before we replace the old
            std::size_t newSize = other.mSize;
            int* newArray = newSize ? new int[newSize]() : nullptr; // (3)
            std::copy(other.mArray, other.mArray + newSize, newArray); // (3)
   
            // replace the old data (all are non-throwing)
            delete [] mArray;
            mSize = newSize;
            mArray = newArray;
        }
   
        return *this;
    }
   

3. ¡El código se ha ampliado! Lo que nos lleva al tercer problema: la duplicación de código.

Nuestro operador de asignación duplica efectivamente todo el código que ya hemos escrito en otros lugares, y eso es algo terrible.

En nuestro caso, el núcleo son solo dos líneas (la asignación y la copia), pero con recursos más complejos este exceso de código puede ser bastante complicado. Debemos esforzarnos por no repetirnos nunca.

(Uno podría preguntarse: si se necesita tanto código para administrar un recurso correctamente, ¿qué pasa si mi clase administra más de uno?
Si bien esto puede parecer una preocupación válida y, de hecho, requiere cláusulas try/ no triviales catch, no es una cuestión trivial. -problema.
¡Eso se debe a que una clase debe administrar un solo recurso !)

Una solución exitosa

Como se mencionó, el modismo copiar e intercambiar solucionará todos estos problemas. Pero ahora mismo tenemos todos los requisitos excepto uno: una swapfunción. Si bien La Regla de Tres implica exitosamente la existencia de nuestro constructor de copias, operador de asignación y destructor, en realidad debería llamarse "Los Tres Grandes y Medio": cada vez que su clase administra un recurso, también tiene sentido proporcionar una función swap. .

Necesitamos agregar la funcionalidad de intercambio a nuestra clase y lo hacemos de la siguiente manera†:

class dumb_array
{
public:
    // ...

    friend void swap(dumb_array& first, dumb_array& second) // nothrow
    {
        // enable ADL (not necessary in our case, but good practice)
        using std::swap;

        // by swapping the members of two objects,
        // the two objects are effectively swapped
        swap(first.mSize, second.mSize);
        swap(first.mArray, second.mArray);
    }

    // ...
};

( Aquí está la explicación del porqué public friend swap.) Ahora no sólo podemos intercambiar nuestros dumb_array's, sino que los intercambios en general pueden ser más eficientes; simplemente intercambia punteros y tamaños, en lugar de asignar y copiar matrices enteras. Aparte de esta ventaja en funcionalidad y eficiencia, ahora estamos listos para implementar el modismo copiar e intercambiar.

Sin más, nuestro operador de asignación es:

dumb_array& operator=(dumb_array other) // (1)
{
    swap(*this, other); // (2)

    return *this;
}

¡Y eso es! De un solo golpe, los tres problemas se abordan con elegancia a la vez.

¿Por qué funciona?

Primero notamos una elección importante: el argumento del parámetro se toma por valor . Si bien uno podría hacer lo siguiente con la misma facilidad (y de hecho, muchas implementaciones ingenuas del modismo lo hacen):

dumb_array& operator=(const dumb_array& other)
{
    dumb_array temp(other);
    swap(*this, temp);

    return *this;
}

Perdemos una importante oportunidad de optimización . No sólo eso, sino que esta elección es fundamental en C++ 11, como se analiza más adelante. (En una nota general, una pauta notablemente útil es la siguiente: si vas a hacer una copia de algo en una función, deja que el compilador lo haga en la lista de parámetros.‡)

De cualquier manera, este método de obtener nuestro recurso es la clave para eliminar la duplicación de código: podemos usar el código del constructor de copia para hacer la copia, y nunca necesitamos repetir nada. Ahora que se realizó la copia, estamos listos para intercambiar.

Observe que al ingresar a la función, todos los datos nuevos ya están asignados, copiados y listos para ser utilizados. Esto es lo que nos brinda una fuerte garantía de excepción de forma gratuita: ni siquiera ingresaremos a la función si falla la construcción de la copia y, por lo tanto, no es posible alterar el estado de *this. (Lo que hicimos manualmente antes para una fuerte garantía de excepción, el compilador lo está haciendo ahora por nosotros; qué amable).

En este punto ya estamos en casa, porque swapno se puede tirar. Intercambiamos nuestros datos actuales con los datos copiados, alterando nuestro estado de forma segura, y los datos antiguos se colocan en el temporal. Los datos antiguos se liberan cuando regresa la función. (Donde termina el alcance del parámetro y se llama a su destructor).

Debido a que el modismo no repite código, no podemos introducir errores dentro del operador. Tenga en cuenta que esto significa que nos libramos de la necesidad de una verificación de autoasignación, lo que permite una implementación única y uniforme de operator=. (Además, ya no tenemos una penalización de rendimiento en tareas que no sean propias).

Y ese es el modismo de copiar e intercambiar.

¿Qué pasa con C++11?

La próxima versión de C++, C++11, realiza un cambio muy importante en la forma en que administramos los recursos: la Regla de Tres ahora es la Regla de Cuatro (y medio). ¿Por qué? Porque no solo necesitamos poder copiar y construir nuestro recurso, sino que también debemos moverlo y construirlo .

Por suerte para nosotros, esto es fácil:

class dumb_array
{
public:
    // ...

    // move constructor
    dumb_array(dumb_array&& other) noexcept ††
        : dumb_array() // initialize via default constructor, C++11 only
    {
        swap(*this, other);
    }

    // ...
};

¿Que está pasando aqui? Recuerde el objetivo de la construcción de movimientos: tomar los recursos de otra instancia de la clase, dejándolos en un estado garantizado para ser asignable y destructible.

Entonces, lo que hemos hecho es simple: inicializar mediante el constructor predeterminado (una característica de C++11), luego intercambiar con other; Sabemos que una instancia construida por defecto de nuestra clase se puede asignar y destruir de forma segura, por lo que sabemos que otherpodremos hacer lo mismo después del intercambio.

(Tenga en cuenta que algunos compiladores no admiten la delegación de constructores; en este caso, tenemos que construir la clase manualmente de forma predeterminada. Esta es una tarea desafortunada pero afortunadamente trivial).

¿Por qué funciona eso?

Ese es el único cambio que debemos hacer en nuestra clase, entonces, ¿por qué funciona? Recuerde la decisión siempre importante que tomamos de hacer del parámetro un valor y no una referencia:

dumb_array& operator=(dumb_array other); // (1)

Ahora, si otherse inicializa con un rvalue, se construirá con movimiento . Perfecto. De la misma manera que C++03 nos permite reutilizar nuestra funcionalidad de constructor de copia tomando el argumento por valor, C++11 también seleccionará automáticamente el constructor de movimiento cuando sea apropiado. (Y, por supuesto, como se mencionó en el artículo vinculado anteriormente, la copia/mover del valor simplemente puede omitirse por completo).

Y así concluye el modismo de copiar e intercambiar.

Notas a pie de página

*¿Por qué lo configuramos mArraycomo nulo? Porque si se genera más código en el operador, dumb_arrayse podría llamar al destructor de; y si eso sucede sin establecerlo en nulo, ¡intentamos eliminar la memoria que ya ha sido eliminada! Evitamos esto configurándolo en nulo, ya que eliminar nulo no es una operación.

†Hay otras afirmaciones de que deberíamos especializarnos std::swappara nuestro tipo, proporcionar una función in-class swapjunto con una función libre swap, etc. Pero todo esto es innecesario: cualquier uso adecuado de swapserá a través de una llamada no calificada, y nuestra función será encontrado a través de ADL . Una función servirá.

‡La razón es simple: una vez que tenga el recurso para usted, puede intercambiarlo y/o moverlo (C++11) a cualquier lugar que necesite. Y al hacer la copia en la lista de parámetros, maximizas la optimización.

††El constructor de movimiento generalmente debería ser noexcept; de lo contrario, algún código (por ejemplo, std::vectorlógica de cambio de tamaño) utilizará el constructor de copia incluso cuando un movimiento tendría sentido. Por supuesto, márquelo solo como no, excepto si el código interno no genera excepciones.

Jul 19 '2010 08:07 GManNickG