Perché l'inizializzazione dell'elenco (usando le parentesi graffe) è migliore delle alternative?

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

Perché?

Non sono riuscito a trovare una risposta su SO, quindi lasciami rispondere alla mia domanda.

Fondamentalmente copia e incolla da "The C ++ Programming Language 4th Edition" di Bjarne Stroustrup :

L'inizializzazione dell'elenco non consente il restringimento (§iso.8.5.4). Questo è:

• Un numero intero non può essere convertito in un altro numero intero che non può contenere il suo valore. Ad esempio, è consentito char to int, ma non int a char.
• Un valore in virgola mobile non può essere convertito in un altro tipo in virgola mobile che non può contenere il suo valore. Ad esempio, float per raddoppiare è consentito, ma non raddoppiare per float.
• Un valore a virgola mobile non può essere convertito in un tipo intero.
• Un valore intero non può essere convertito in un tipo a virgola mobile.

Esempio:

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)

}

L' unica situazione in cui = è preferito su {} è quando si utilizza la autoparola chiave per ottenere il tipo determinato dall'inizializzatore.

Esempio:

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

Conclusione

Preferisci {} l'inizializzazione rispetto alle alternative a meno che tu non abbia un motivo valido per non farlo.

Esistono già ottime risposte sui vantaggi dell'utilizzo dell'inizializzazione dell'elenco, tuttavia la mia regola empirica personale NON è quella di utilizzare le parentesi graffe quando possibile, ma invece di renderlo dipendente dal significato concettuale:

• Se l'oggetto che sto creando concettualmente contiene i valori che sto passando nel costruttore (ad es. Container, strutture POD, atomica, puntatori intelligenti ecc.), Allora sto usando le parentesi graffe.
• Se il costruttore assomiglia a una normale chiamata di funzione (esegue alcune operazioni più o meno complesse che sono parametrizzate dagli argomenti) allora sto usando la normale sintassi della chiamata di funzione.
• Per l'inizializzazione predefinita uso sempre parentesi graffe.
  Per uno, in questo modo sono sempre sicuro che l'oggetto viene inizializzato indipendentemente dal fatto che sia ad esempio una classe "reale" con un costruttore predefinito che verrebbe chiamato comunque o un tipo incorporato / POD. In secondo luogo, nella maggior parte dei casi, è coerente con la prima regola, poiché un oggetto inizializzato predefinito rappresenta spesso un oggetto "vuoto".

Nella mia esperienza, questo set di regole può essere applicato in modo molto più coerente rispetto all'uso di parentesi graffe per impostazione predefinita, ma dover ricordare esplicitamente tutte le eccezioni quando non possono essere utilizzate o hanno un significato diverso rispetto alla "normale" sintassi di chiamata di funzione con parentesi (chiama un sovraccarico diverso).

Ad esempio si adatta perfettamente a tipi di libreria standard come 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

Esistono MOLTE ragioni per utilizzare l'inizializzazione del controvento, ma è necessario tenere presente che il initializer_list<>costruttore è preferito agli altri costruttori , con l'eccezione che è il costruttore predefinito. Ciò porta a problemi con costruttori e modelli in cui il tipo Tcostruttore può essere un elenco di inizializzatori o un semplice vecchio ctor.

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!!!
}

Supponendo che non si incontrino tali classi, ci sono pochi motivi per non utilizzare l'elenco degli inizializzatori.

È solo più sicuro finché non si costruisce con -Wno-restringimento come dire Google fa in Chromium. Se lo fai, allora è MENO sicuro. Senza quella bandiera, tuttavia, gli unici casi non sicuri verranno risolti da C ++ 20.

Nota: A) Le parentesi graffe sono più sicure perché non consentono il restringimento. B) Le parentesi graffe sono meno sicure perché possono bypassare costruttori privati ​​o eliminati e chiamare implicitamente costruttori espliciti contrassegnati.

Quei due combinati significano che sono più sicuri se ciò che è dentro sono costanti primitive, ma meno sicuri se sono oggetti (sebbene risolti in C ++ 20)