Qu'est-ce que l'idiome "copier-échanger"?

(non seulement cela, mais des appels sans réserve à swap opérateur de swap personnalisé, en sautant sur la construction inutile et la destruction de notre classe que std::swap entraînerait.)

une explication en profondeur

le but

considérons un cas concret. Nous voulons gérer autrement inutile de classe, un tableau dynamique. Nous commençons par un constructeur, Un copy-constructor et un destructeur:

#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;
};

This classe presque gère le tableau avec succès, mais il a besoin de "1519140920 pour fonctionner correctement.

l'échec d'Une solution

voici à quoi pourrait ressembler une implémentation naïve:

// 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;
}

et nous disons que nous sommes finis; cela gère maintenant un réseau, sans fuites. Cependant, il souffre de trois problèmes, marqués séquentiellement dans le code comme (n) .

1. le premier est le test d'auto-assignation. Cette vérification sert à deux fins: c'est un moyen facile de nous empêcher d'exécuter du code inutile sur l'auto-assignation, et elle nous protège des bogues subtils (comme supprimer le tableau uniquement pour essayer de le copier). Mais dans tous les autres cas, il sert simplement à ralentir le programme, et agir comme bruit dans le code; auto-assignation se produit rarement, donc la plupart du temps cette vérification est un gaspillage. Il serait préférable que l'opérateur puisse travailler correctement sans elle.

2. la seconde est qu'elle ne fournit qu'une garantie d'exception de base. Si new int[mSize] échoue, *this aura été modifié. (À savoir, la taille est fausse et les données ont disparu!) Pour une garantie d'exception forte, il faudrait qu'elle s'apparente à:

   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. le code a été élargi! Ce qui nous amène au troisième problème: la duplication de code. Notre opérateur de mission duplique efficacement tout le code que nous avons déjà écrit ailleurs, et c'est une chose terrible.

dans notre cas, le cœur de celui-ci est seulement deux lignes (l'allocation et la copie), mais avec des ressources plus complexes ce code bloat peut être tout à fait un tracas. Nous devrions nous efforcer de ne jamais nous répéter.

(On peut se demander: si ce code est nécessaire pour gérer une ressource correctement, et si ma classe gère plus d'un? Bien que cela puisse sembler être une préoccupation valable, et en effet, il exige des clauses non triviales try / catch , il s'agit d'une non-question. C'est parce qu'une classe devrait gérer une seule ressource !)

une solution réussie

comme mentionné, l'idiome de copie-et-échange réglera tous ces problèmes. Mais pour l'instant, nous avons toutes les exigences sauf une: une fonction swap . Alors que la règle des trois implique avec succès l'existence de notre copy-constructor, assignment operator, et destructor, devrait vraiment s'appeler "The Big Three and a Half": chaque fois que votre classe gère une ressource, il est également logique de fournir une fonction swap .

Nous avons besoin d'ajouter la fonctionnalité de démontage à notre classe, et nous le faisons comme suit†:

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);
    }

    // ...
};

( Ici est l'explication de pourquoi public friend swap .) Non seulement pouvons-nous échanger nos dumb_array 's, mais les échanges en général peut être plus efficace; il échange simplement des pointeurs et des tailles, plutôt que d'allouer et de copier des tableaux entiers. En plus de ce bonus de fonctionnalité et d'efficacité, nous sommes maintenant prêts à mettre en œuvre l'idiome copie-échange.

sans plus attendre, notre opérateur d'affectation est:

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

    return *this;
}

Et c'est tout! Avec un seul coup, tous les trois problèmes sont élégamment abordé à la fois.

pourquoi ça marche?

nous remarquons d'abord un choix important: l'argument de paramètre est pris by-value . Alors que l'on pourrait tout aussi bien faire ce qui suit (et en effet, de nombreuses implémentations naïves de l'idiome le font):

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

    return *this;
}

Nous perdons un important de l'optimisation des chances . Non seulement cela, mais ce choix est critique en C++11, qui est discuté plus tard. (Sur une note générale, une ligne directrice remarquablement utile est la suivante: si vous allez faire une copie de quelque chose dans une fonction, laisser le compilateur faire dans la liste des paramètres.‡ )

quoi qu'il en soit, cette méthode d'obtention de notre ressource est la clé pour éliminer la duplication de code: nous obtenons d'utiliser le code du copy-constructor pour faire la copie, et n'avons jamais besoin de répéter un peu de celui-ci. Maintenant que la copie est faite, nous sommes prêts à échanger.

Observer qu'en entrant dans la fonction que toutes les nouvelles données sont déjà attribués, copié, et prêt à être utilisé. C'est ce qui nous donne une forte garantie d'exception gratuite: nous n'entrerons même pas la fonction si la construction de la copie échoue, et il n'est donc pas possible de modifier l'état de *this . (Ce que nous avons fait manuellement auparavant pour une forte garantie d'exception, le compilateur le fait pour nous maintenant; comment aimable.)

à ce point nous sommes à la maison libre, parce que swap est non-lanceur. Nous échangeons nos données actuelles avec les données copiées, en toute sécurité changer notre état, et les vieilles données sont mises dans le temporaire. Les anciennes données sont ensuite libérés lorsque la fonction retourne. (Où sur la portée du paramètre se termine et son destructeur est appelé.)

parce que l'idiome ne répète aucun code, nous ne pouvons pas introduire de bogues dans l'opérateur. Notez que cela signifie que nous sommes débarrassés de la nécessité d'une vérification d'auto-assignation, permettant une mise en œuvre uniforme unique de operator= . (En outre, nous n'avons plus les performances sur non-auto-affectations.)

et c'est l'idiome de la copie et de l'échange.

Qu'en est-il de C++11?

la prochaine version de C++, C++11, apporte un changement très important à la gestion des ressources: la règle des trois est maintenant la règle des quatre (et demi). Pourquoi? Parce que non seulement nous devons être en mesure de copier-construire notre ressource, nous devons aller au-construire ainsi .

Heureusement pour nous, c'est facile:

class dumb_array
{
public:
    // ...

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

    // ...
};

que se passe-t-il? Rappelons le but de move-construction: prendre les ressources d'une autre instance de la classe, la laissant dans un État garanti pour être assignable et destructible.

donc ce que nous avons fait est simple: initialiser via le constructeur par défaut (une fonctionnalité C++11), puis échanger avec other ; nous savons qu'une instance construite par défaut de notre classe peut être assignée en toute sécurité et détruit, donc nous savons que other sera capable de faire la même chose, après l'échange.

(notez que certains compilateurs ne prennent pas en charge la délégation du constructeur; dans ce cas, nous devons construire manuellement la classe par défaut. C'est regrettable, mais heureusement tâche triviale.)

pourquoi ça marche?

C'est le seul changement que nous devons apporter à notre classe, alors pourquoi faut-il travailler? Rappelez - vous la décision toujours importante que nous avons prise de faites du paramètre une valeur et non une référence:

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

Maintenant, si other est initialisé avec une rvalue, il sera construit . Parfait. De la même manière C++03 permet de réutiliser notre fonctionnalité de copy-constructor en prenant l'argument by-value, C++11 va automatiquement choisir le move-constructor quand approprié aussi bien. (Et, bien sûr, comme mentionné dans l'article lié la copie / le déplacement de la valeur peut tout simplement être effacé.)

et conclut ainsi l'idiome de copie et d'échange.

notes

*Pourquoi avons-nous ensemble mArray à null? Parce que si un autre code dans l'opérateur lance, le destructeur de dumb_array pourrait être appelé; et si cela arrive sans le mettre à zéro, nous essayons de supprimer la mémoire qui a déjà été supprimée! Nous évitons cela en la définir à null, comme supprimer null est une non-opération.

†il y a d'autres revendications que nous devrions spécialiser std::swap pour notre type, fournir un dans la classe swap le long d'une fonction libre swap , etc. Mais cela n'est pas nécessaire: toute utilisation correcte de swap sera par un appel sans réserve, et notre fonction sera trouvée par ADL . Une fonction ne se.

‡la raison est simple: une fois que vous avoir la ressource pour vous - même, vous pouvez l'échanger et/ou la déplacer (C++11) n'importe où il doit être. Et en faire la copie dans la liste des paramètres, vous maximisez l'optimisation.