Pourquoi l'initialisation de la liste (en utilisant des accolades) est-elle meilleure que les alternatives?

MyClass a1 {a};     // clearer and less error-prone than the other three
MyClass a2 = {a};
MyClass a3 = a;
MyClass a4(a);

Pourquoi?

Je n'ai pas pu trouver de réponse sur SO, alors laissez-moi répondre à ma propre question.

Fondamentalement, copier et coller à partir de "The C ++ Programming Language 4th Edition" de Bjarne Stroustrup :

L'initialisation de liste ne permet pas de rétrécissement (§iso.8.5.4). C'est:

• Un entier ne peut pas être converti en un autre entier qui ne peut pas contenir sa valeur. Par exemple, char to int est autorisé, mais pas int to char.
• Une valeur à virgule flottante ne peut pas être convertie en un autre type à virgule flottante qui ne peut pas contenir sa valeur. Par exemple, flotter pour doubler est autorisé, mais pas double pour flotter.
• Une valeur à virgule flottante ne peut pas être convertie en type entier.
• Une valeur entière ne peut pas être convertie en type à virgule flottante.

Exemple:

void fun(double val, int val2) {

    int x2 = val; // if val==7.9, x2 becomes 7 (bad)

    char c2 = val2; // if val2==1025, c2 becomes 1 (bad)

    int x3 {val}; // error: possible truncation (good)

    char c3 {val2}; // error: possible narrowing (good)

    char c4 {24}; // OK: 24 can be represented exactly as a char (good)

    char c5 {264}; // error (assuming 8-bit chars): 264 cannot be 
                   // represented as a char (good)

    int x4 {2.0}; // error: no double to int value conversion (good)

}

La seule situation où = est préféré à {} consiste à utiliser un automot-clé pour obtenir le type déterminé par l'initialiseur.

Exemple:

auto z1 {99};   // z1 is an int
auto z2 = {99}; // z2 is std::initializer_list<int>
auto z3 = 99;   // z3 is an int

Conclusion

Préférez l'initialisation {} aux alternatives, sauf si vous avez une bonne raison de ne pas le faire.

Il existe déjà d'excellentes réponses concernant les avantages de l'initialisation de liste, mais ma règle de base personnelle n'est PAS d'utiliser des accolades chaque fois que possible, mais de la rendre dépendante de la signification conceptuelle:

• Si l'objet que je crée contient conceptuellement les valeurs que je passe dans le constructeur (par exemple, conteneurs, structures POD, atomiques, pointeurs intelligents, etc.), alors j'utilise les accolades.
• Si le constructeur ressemble à un appel de fonction normal (il effectue des opérations plus ou moins complexes qui sont paramétrées par les arguments), alors j'utilise la syntaxe d'appel de fonction normale.
• Pour l'initialisation par défaut, j'utilise toujours des accolades.
  D'une part, de cette façon, je suis toujours sûr que l'objet est initialisé, qu'il s'agisse par exemple d'une "vraie" classe avec un constructeur par défaut qui serait appelé de toute façon ou d'un type intégré / POD. Deuxièmement, il est - dans la plupart des cas - conforme à la première règle, car un objet initialisé par défaut représente souvent un objet "vide".

D'après mon expérience, cet ensemble de règles peut être appliqué de manière beaucoup plus cohérente que l'utilisation d'accolades par défaut, mais avoir à se souvenir explicitement de toutes les exceptions lorsqu'elles ne peuvent pas être utilisées ou ont une signification différente de la syntaxe "normale" d'appel de fonction avec parenthèses (appelle une surcharge différente).

Il s'intègre par exemple parfaitement avec les types de bibliothèques standard comme std::vector:

vector<int> a{10,20};   //Curly braces -> fills the vector with the arguments

vector<int> b(10,20);   //Parentheses -> uses arguments to parametrize some functionality,                          
vector<int> c(it1,it2); //like filling the vector with 10 integers or copying a range.

vector<int> d{};      //empty braces -> default constructs vector, which is equivalent
                      //to a vector that is filled with zero elements

Il y a BEAUCOUP de raisons d'utiliser l'initialisation de l'accolade, mais vous devez savoir que le initializer_list<>constructeur est préféré aux autres constructeurs , l'exception étant le constructeur par défaut. Cela entraîne des problèmes avec les constructeurs et les modèles où le Tconstructeur de type peut être soit une liste d'initialisation, soit un ancien ctor simple.

struct Foo {
    Foo() {}

    Foo(std::initializer_list<Foo>) {
        std::cout << "initializer list" << std::endl;
    }

    Foo(const Foo&) {
        std::cout << "copy ctor" << std::endl;
    }
};

int main() {
    Foo a;
    Foo b(a); // copy ctor
    Foo c{a}; // copy ctor (init. list element) + initializer list!!!
}

En supposant que vous ne rencontriez pas de telles classes, il y a peu de raisons de ne pas utiliser la liste des initialiseurs.

C'est plus sûr aussi longtemps que vous ne construisez pas avec -Wno-restricting comme disons Google dans Chromium. Si vous le faites, alors c'est MOINS sûr. Sans cet indicateur, les seuls cas dangereux seront corrigés par C ++ 20.

Remarque: A) Les accolades sont plus sûres car elles ne permettent pas de rétrécissement. B) Les accolades sont moins sûres car elles peuvent contourner les constructeurs privés ou supprimés, et appeler implicitement les constructeurs marqués explicitement.

Ces deux combinés signifient qu'ils sont plus sûrs si ce qui est à l'intérieur sont des constantes primitives, mais moins sûrs si ce sont des objets (bien qu'ils soient fixes en C ++ 20)