Dlaczego inicjalizacja listy (przy użyciu nawiasów klamrowych) jest lepsza niż alternatywy?

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

Dlaczego?

Nie mogłem znaleźć odpowiedzi na SO, więc pozwól mi odpowiedzieć na własne pytanie.

Zasadniczo kopiowanie i wklejanie z „The C ++ Programming Language 4th Edition” Bjarne Stroustrupa :

Inicjalizacja listy nie pozwala na zawężenie (§iso.8.5.4). To jest:

• Liczby całkowitej nie można przekonwertować na inną liczbę całkowitą, która nie może utrzymać swojej wartości. Na przykład char do int jest dozwolone, ale nie int do char.
• Wartości zmiennoprzecinkowej nie można przekonwertować na inny typ zmiennoprzecinkowy, który nie może utrzymać swojej wartości. Na przykład dozwolona jest liczba zmiennoprzecinkowa, ale nie liczba zmiennoprzecinkowa
• Wartości zmiennoprzecinkowej nie można przekonwertować na typ całkowity.
• Wartości całkowitej nie można przekonwertować na typ zmiennoprzecinkowy.

Przykład:

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)

}

Jedynie sytuacja, w której jest korzystniejszy = {} jest przy użyciu autosłowa kluczowego, aby uzyskać typ określony przez inicjatora.

Przykład:

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

Wniosek

Preferuj inicjalizację {} zamiast alternatywnych, chyba że masz wyraźny powód, aby tego nie robić.

Istnieją już świetne odpowiedzi na temat zalet korzystania z inicjalizacji listy, jednak moją osobistą zasadą jest, aby NIE używać nawiasów klamrowych, gdy tylko jest to możliwe, ale uzależnić je od znaczenia pojęciowego:

• Jeśli obiekt, który tworzę koncepcyjnie, zawiera wartości, które przekazuję w konstruktorze (np. Kontenery, struktury POD, atomics, inteligentne wskaźniki itp.), To używam nawiasów klamrowych.
• Jeśli konstruktor przypomina normalne wywołanie funkcji (wykonuje mniej lub bardziej złożone operacje sparametryzowane przez argumenty), to używam normalnej składni wywołania funkcji.
• Do domyślnej inicjalizacji zawsze używam nawiasów klamrowych.
  Po pierwsze, w ten sposób zawsze jestem pewien, że obiekt zostanie zainicjowany niezależnie od tego, czy np. Jest to „prawdziwa” klasa z domyślnym konstruktorem, który i tak zostanie wywołany, czy też ma wbudowany / POD typ. Po drugie - w większości przypadków - jest zgodny z pierwszą regułą, ponieważ domyślnie zainicjowany obiekt często reprezentuje „pusty” obiekt.

Z mojego doświadczenia wynika, że ​​ten zestaw reguł można stosować znacznie bardziej konsekwentnie niż domyślnie stosowanie nawiasów klamrowych, ale trzeba wyraźnie pamiętać wszystkie wyjątki, gdy nie można ich użyć lub mają inne znaczenie niż „normalna” składnia wywołania funkcji z nawiasami (wywołuje inne przeciążenie).

Np. Dobrze pasuje do standardowych typów bibliotek, takich jak 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

Istnieje wiele powodów, aby inicjalizacji użycie nawiasów, ale należy pamiętać, że konstruktor jest korzystne dla innych konstruktorów , wyjątkiem jest domyślnym-konstruktor. Prowadzi to do problemów z konstruktorami i szablonami, w których konstruktorem typów może być lista inicjalizująca lub zwykły stary ctor.initializer_list<>T

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

Zakładając, że nie spotkasz się z takimi klasami, nie ma powodu, aby nie używać listy intializatora.

Jest to bezpieczniejsze tylko pod warunkiem, że nie budujesz z -nie zawężaniem, jak powiedzmy, że Google robi w Chromium. Jeśli tak, to MNIEJ bezpieczniej. Bez tej flagi jedyne niebezpieczne przypadki zostaną naprawione przez C ++ 20.

Uwaga: A) Nawiasy klamrowe są bezpieczniejsze, ponieważ nie pozwalają na zwężenie. B) Nawiasy klamrowe są mniej bezpieczne, ponieważ mogą ominąć konstruktory prywatne lub usunięte i wywołać jawnie oznaczone konstruktory.

Te dwie kombinacje oznaczają, że są bezpieczniejsze, jeśli to, co jest w środku, jest prymitywnymi stałymi, ale mniej bezpieczne, jeśli są obiektami (chociaż ustalone w C ++ 20)