Différence entre l'initialisateur et la liste d'initialiseurs par défaut en C ++

pris de Section 10.6 de la FAQ C ++ Par Marshall Cline:

Listes d'initialisation. En réalité, Les constructeurs doivent initialiser en tant que Règle tous les objets membres dans le Liste d'initialisation. Une exception est discuté plus loin.

Considérez le constructeur suivant qui initialise l'objet membre x_ Utilisation d'une liste d'initialisation: Fred :: Fred (): x_ (peu importe) {}. Les avantage le plus courant de faire cela est performance améliorée. Par exemple, si l'expression quel que soit le même Tapez la variable de membre X_, le résultat de l'expression quelle que soit construit directement à l'intérieur de x_ - le compilateur ne fait pas une copie séparée de l'objet. Même si les types sont Pas la même chose, le compilateur est généralement capable de faire un meilleur travail avec Listes d'initialisation qu'avec missions.

l'autre moyen (inefficace) de construire constructeurs est via une mission, telle AS: Fred :: Fred () {x_ = autre chose; }. Dans ce cas, l'expression autre chose provoque un objet séparé et temporaire à être créé et cet objet temporaire est transmis dans l'objet x_ opérateur d'assignation. Alors que objet temporaire est détruit à la ;. C'est inefficace.

comme si cela n'était pas assez mauvais, il y a une autre source d'inefficacité lorsque Utilisation de l'affectation dans un constructeur: le L'objet membre sera pleinement construit par sa valeur par défaut constructeur, et cela pourrait, pour exemple, allouer un montant par défaut de mémoire ou ouvrez certains fichiers par défaut. Tout ce travail pourrait être pour rien que l'expression et / ou / ou L'opérateur d'affectation provoque l'objet fermer ce fichier et / ou libérer ce Mémoire (par exemple, si la valeur par défaut constructeur n'a pas alloué un grand assez de piscine de mémoire ou si elle a ouvert le mauvais fichier).

Conclusion: Toutes les autres choses étant égal, votre code fonctionnera plus vite si Vous utilisez plutôt des listes d'initialisation que l'affectation.

Remarque: il n'y a pas de performance différence si le type de x_ est un peu type intégré / intrinsèque, tel que INT ou char * ou float. Mais même dans ces cas, ma préférence personnelle est de Définissez ces membres de données dans le liste d'initialisation plutôt que via affectation pour la cohérence. Un autre argument de symétrie en faveur de l'utilisation de Listes d'initialisation même pour Types intégrés / intrinsèques: non statique Données de référence Const et non statiques Les membres ne peuvent pas être attribués une valeur dans le constructeur, donc pour la symétrie a du sens d'initialiser tout Dans la liste d'initialisation.

Maintenant pour les exceptions. Chaque règle a exceptions (hmmm; fait "chaque règle a exceptions "ont des exceptions? rappelle moi de l'incomplétude de Gödel Théorèmes), et il y a deux exceptions à "l'initialisation de l'utilisation Listes "règle. La ligne de fond est à utiliser Bon sens: si c'est moins cher, mieux, plus rapide, etc. pour ne pas les utiliser, puis par Tous les moyens ne les utilisent pas. Cela pourrait arriver quand votre classe a deux constructeurs qui doivent initialiser les membres de données de ce objet dans ordres différents. Ou cela pourrait arriver Quand deux membres de données sont auto-référentiel. Ou quand un Les données-membres ont besoin d'une référence à la Cet objet, et vous voulez éviter un Avertissement du compilateur sur l'utilisation de la ceci mot clé avant le {qui commence la corps du constructeur (quand votre Un compilateur particulier arrive à émettre cet avertissement particulier). Ou quand vous besoin de faire un test si / lancer sur un Variable (paramètre, global, etc.) avant d'utiliser cette variable pour initialiser l'un de vos membres. Cette liste n'est pas exhaustive; s'il te plaît Ne m'écris pas me demandant d'ajouter un autre "ou quand ...". Le point est Simplement ceci: utiliser le bon sens.