introduction
C ++ traite les variables de types définis par l'utilisateur avec une sémantique de valeur . Cela signifie que les objets sont implicitement copiés dans divers contextes, et nous devons comprendre ce que signifie réellement "copier un objet".
Prenons un exemple simple:
class person
{
std::string name;
int age;
public:
person(const std::string& name, int age) : name(name), age(age)
{
}
};
int main()
{
person a("Bjarne Stroustrup", 60);
person b(a); // What happens here?
b = a; // And here?
}
(Si la partie vous laisse perplexe name(name), age(age), cela s'appelle une liste d'initialisation de membre .)
Fonctions spéciales des membres
Que signifie copier un personobjet? La mainfonction affiche deux scénarios de copie distincts. L'initialisation person b(a);est effectuée par le constructeur de copie . Son travail consiste à construire un nouvel objet en fonction de l'état d'un objet existant. L'affectation b = aest effectuée par l' opérateur d'affectation de copie . Son travail est généralement un peu plus compliqué, car l'objet cible est déjà dans un état valide qui doit être traité.
Puisque nous n'avons déclaré ni le constructeur de copie ni l'opérateur d'affectation (ni le destructeur) nous-mêmes, ceux-ci sont implicitement définis pour nous. Citation de la norme:
Le constructeur de copie et l'opérateur d'affectation de copie, [...] et le destructeur sont des fonctions membres spéciales. [ Remarque : L'implémentation déclarera implicitement ces fonctions membres pour certains types de classe lorsque le programme ne les déclare pas explicitement.
L'implémentation les définira implicitement si elles sont utilisées. [...] note de fin ] [n3126.pdf section 12 §1]
Par défaut, copier un objet signifie copier ses membres:
Le constructeur de copie défini implicitement pour une classe non-union X effectue une copie membre par membre de ses sous-objets. [n3126.pdf section 12.8 §16]
L'opérateur d'affectation de copie défini implicitement pour une classe non-union X effectue l'affectation de copie par membre de ses sous-objets. [n3126.pdf section 12.8 §30]
Définitions implicites
Les fonctions membres spéciales définies implicitement pour personressemblent à ceci:
// 1. copy constructor
person(const person& that) : name(that.name), age(that.age)
{
}
// 2. copy assignment operator
person& operator=(const person& that)
{
name = that.name;
age = that.age;
return *this;
}
// 3. destructor
~person()
{
}
La copie par membre est exactement ce que nous voulons dans ce cas:
nameet ageest copiée, nous obtenons donc un personobjet indépendant et indépendant . Le destructeur défini implicitement est toujours vide. C'est également très bien dans ce cas puisque nous n'avons acquis aucune ressource dans le constructeur. Les destructeurs des membres sont implicitement appelés une fois le persondestructeur terminé:
Après avoir exécuté le corps du destructeur et détruit tous les objets automatiques alloués dans le corps, un destructeur pour la classe X appelle les destructeurs des membres directs de X [n3126.pdf 12.4 §6]
Gérer les ressources
Alors, quand devrions-nous déclarer explicitement ces fonctions membres spéciales? Lorsque notre classe gère une ressource , c'est-à-dire lorsqu'un objet de la classe est responsable de cette ressource. Cela signifie généralement que la ressource est acquise dans le constructeur (ou transmise au constructeur) et libérée dans le destructeur.
Remontons le temps au C ++ pré-standard. Il n'y avait rien de tel std::string, et les programmeurs étaient amoureux des pointeurs. La personclasse aurait pu ressembler à ceci:
class person
{
char* name;
int age;
public:
// the constructor acquires a resource:
// in this case, dynamic memory obtained via new[]
person(const char* the_name, int the_age)
{
name = new char[strlen(the_name) + 1];
strcpy(name, the_name);
age = the_age;
}
// the destructor must release this resource via delete[]
~person()
{
delete[] name;
}
};
Aujourd'hui encore, les gens écrivent des cours dans ce style et ont des ennuis: " J'ai poussé une personne dans un vecteur et maintenant j'ai des erreurs de mémoire folles! " Rappelez-vous que par défaut, copier un objet signifie copier ses membres, mais copier le namemembre simplement copie un pointeur, pas le tableau de caractères vers lequel il pointe! Cela a plusieurs effets désagréables:
- Les modifications via
apeuvent être observées via b.
- Une fois
bdétruit, se a.nametrouve un pointeur suspendu.
- Si
aest détruit, la suppression du pointeur pendant entraîne un comportement indéfini .
- Étant donné que l'affectation ne prend pas en compte ce qui était
nameindiqué avant l'affectation, tôt ou tard, vous obtiendrez des fuites de mémoire partout.
Définitions explicites
Étant donné que la copie par membre n'a pas l'effet souhaité, nous devons définir explicitement le constructeur de copie et l'opérateur d'affectation de copie pour effectuer des copies complètes du tableau de caractères:
// 1. copy constructor
person(const person& that)
{
name = new char[strlen(that.name) + 1];
strcpy(name, that.name);
age = that.age;
}
// 2. copy assignment operator
person& operator=(const person& that)
{
if (this != &that)
{
delete[] name;
// This is a dangerous point in the flow of execution!
// We have temporarily invalidated the class invariants,
// and the next statement might throw an exception,
// leaving the object in an invalid state :(
name = new char[strlen(that.name) + 1];
strcpy(name, that.name);
age = that.age;
}
return *this;
}
Notez la différence entre l'initialisation et l'affectation: nous devons supprimer l'ancien état avant de l'affecter namepour éviter les fuites de mémoire. Nous devons également nous protéger contre l'auto-affectation du formulaire x = x. Sans cette vérification, delete[] namesupprimerait le tableau contenant la source de chaîne, parce que quand vous écrivez x = x, à la fois this->nameet that.namecontiennent le même pointeur.
Sécurité d'exception
Malheureusement, cette solution échouera si new char[...]lève une exception en raison de l'épuisement de la mémoire. Une solution possible consiste à introduire une variable locale et à réorganiser les instructions:
// 2. copy assignment operator
person& operator=(const person& that)
{
char* local_name = new char[strlen(that.name) + 1];
// If the above statement throws,
// the object is still in the same state as before.
// None of the following statements will throw an exception :)
strcpy(local_name, that.name);
delete[] name;
name = local_name;
age = that.age;
return *this;
}
Cela prend également en charge l'auto-affectation sans vérification explicite. Une solution encore plus robuste à ce problème est l' idiome de copie et d'échange , mais je n'entrerai pas dans les détails de la sécurité des exceptions ici. J'ai seulement mentionné des exceptions pour faire le point suivant: Écrire des classes qui gèrent des ressources est difficile.
Ressources non copiables
Certaines ressources ne peuvent pas ou ne doivent pas être copiées, comme les descripteurs de fichiers ou les mutex. Dans ce cas, déclarez simplement le constructeur de copie et l'opérateur d'affectation de copie comme privatesans donner de définition:
private:
person(const person& that);
person& operator=(const person& that);
Alternativement, vous pouvez les hériter boost::noncopyableou les déclarer supprimés (en C ++ 11 et supérieur):
person(const person& that) = delete;
person& operator=(const person& that) = delete;
La règle des trois
Parfois, vous devez implémenter une classe qui gère une ressource. (Ne gérez jamais plusieurs ressources dans une seule classe, cela ne fera que causer de la douleur.) Dans ce cas, rappelez-vous la règle des trois :
Si vous devez déclarer vous-même explicitement le destructeur, le constructeur de copie ou l'opérateur d'affectation de copie, vous devez probablement déclarer explicitement les trois.
(Malheureusement, cette "règle" n'est pas appliquée par la norme C ++ ou par tout compilateur que je connaisse.)
La règle des cinq
À partir de C ++ 11, un objet possède 2 fonctions membres spéciales supplémentaires: le constructeur de déplacement et l'affectation de déplacement. La règle des cinq États met également en œuvre ces fonctions.
Un exemple avec les signatures:
class person
{
std::string name;
int age;
public:
person(const std::string& name, int age); // Ctor
person(const person &) = default; // Copy Ctor
person(person &&) noexcept = default; // Move Ctor
person& operator=(const person &) = default; // Copy Assignment
person& operator=(person &&) noexcept = default; // Move Assignment
~person() noexcept = default; // Dtor
};
La règle du zéro
La règle de 3/5 est également appelée la règle de 0/3/5. La partie zéro de la règle indique que vous êtes autorisé à n'écrire aucune des fonctions membres spéciales lors de la création de votre classe.
Conseil
La plupart du temps, vous n'avez pas besoin de gérer vous-même une ressource, car une classe existante telle que std::stringdéjà le fait pour vous. Comparez simplement le code simple utilisant un std::stringmembre à l'alternative alambiquée et sujette aux erreurs en utilisant un char*et vous devriez être convaincu. Tant que vous restez à l'écart des membres du pointeur brut, la règle de trois ne concernera probablement pas votre propre code.
c++-faqwiki du tag avant de voter pour fermer .