La vérification « if (this != &rhs) » est-elle nécessaire dans un opérateur d'affectation de déplacement ?

Déplacer l'opérateur d'affectation et if (this != &rhs)

Dans les opérateurs d'affectation de copie standard pour les classes, il est courant de vérifier si l'objet attribué est le identique à l'objet appelant en utilisant if (this != &rhs) pour éviter de modifier l'objet appelant. Mais cette vérification est-elle nécessaire pour l'opérateur d'affectation de déplacement ?

Sémantique de déplacement

L'opérateur d'affectation de déplacement, noté Operator=(Class&&), est conçu pour transférer efficacement la propriété des ressources. d'un objet à un autre. Contrairement à l'affectation de copie, cela évite d'avoir à créer une nouvelle copie de l'objet.

Analyse de la situation

Est-ce que cela == &rhs ?

La question se pose de savoir si ceci == &rhs peut un jour être vrai dans un opérateur d'affectation de déplacement.

Il existe deux scénarios lorsqu'un objet se lie à une référence rvalue :

1. C'est un véritable objet temporaire.
2. C'est un objet que l'appelant prétend être temporaire.

Dans le premier cas, parce que l'objet est une référence unique à un objet temporaire, cela == &rhs est impossible. Dans le deuxième cas, il est de la responsabilité de l'appelant de s'assurer que this != &rhs, rendant la vérification inutile.

Argument pour ne pas vérifier

L'auteur soutient que le if (this != &rhs) le chèque est redondant car :

• L'auto-affectation pour les intérimaires est impossible.
• Les clients qui trompent intentionnellement l'opérateur doivent corriger leur code.

En omettant cette vérification, les performances peuvent être améliorées dans les situations où les objets sont fréquemment déplacés et attribués à eux-mêmes.

Argument en faveur de la vérification

Cependant, certains soutiennent que la vérification this != &rhs est toujours nécessaire pour empêcher l'auto-affectation de mouvement. Ils soutiennent qu'autoriser swap(x, x) comme opération valide pourrait déclencher cette vérification.

Solution et considérations

L'auteur conclut que :

Copier et Conditions post-affectation de déplacement :

• Copier l'affectation : La valeur de y doit rester inchangée, y compris dans le cas d'une affectation d'auto-copie.
• Affectation de déplacement : y doit avoir un état valide mais non spécifié, y compris pour une affectation d'auto-déplacement.

Auto-déplacement-affectation Implémentation :

Pour y parvenir, trois implémentations possibles pour l'opérateur d'affectation de déplacement dans une classe comme dumb_array sont fournies :

1. Une vérification est effectuée pour distinguer l'auto-déplacement-affectation, et l'objet est défini sur un état valide avant en cours.

2. L'enregistrement a été omis, ce qui rend l'affectation automatique des déplacements impossible.

3. L'échange (autre ) est utilisée, à condition que la classe ne détienne pas de ressources qui devraient être immédiatement libérées.

L'auteur souligne que la meilleure implémentation dépend de la conception spécifique de la classe, des caractéristiques matérielles et des exigences de performances.

Dans les cas où la classe ne gère pas directement la mémoire, il suggère d'utiliser Operator=(Class& &) = par défaut ; pour atteindre les performances les plus élevées avec une sécurité d'exception de base.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!