Чому ініціалізація списку (за допомогою фігурних дужок) краща за альтернативи?

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

Чому?

Я не зміг знайти відповідь на ТА, тому дозвольте мені відповісти на власне запитання.

В основному копіювання та вставлення з "4-ї редакції мови програмування" Bjarne Stroustrup :

Ініціалізація списку не дозволяє звужуватися (§iso.8.5.4). Це є:

• Ціле число не може бути перетворене в інше ціле число, яке не може утримувати його значення. Наприклад, char до int дозволено, але не int to char.
• Значення з плаваючою комою не може бути перетворене в інший тип з плаваючою комою, який не може утримувати своє значення. Наприклад, дозволено плавати в два рази, але не плавати вдвічі.
• Значення з плаваючою комою не можна перетворити на цілий тип.
• Ціле значення не можна перетворити на тип з плаваючою комою.

Приклад:

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)

}

Тільки ситуація , коли = краще , ніж {}, коли з допомогою autoключового слова , щоб отримати тип , який визначається ініціалізатор.

Приклад:

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

Висновок

Віддайте перевагу {} ініціалізації над альтернативами, якщо у вас немає вагомих причин цього не робити.

Про переваги використання ініціалізації списку вже є чудові відповіді, однак моє особисте правило - НЕ використовувати фігурні дужки, коли це можливо, а замість цього зробити залежним від понятійного значення:

• Якщо об'єкт, який я створюю концептуально, містить значення, які я передаю в конструкторі (наприклад, контейнери, структури POD, атома, розумні покажчики тощо), то я використовую дужки.
• Якщо конструктор нагадує звичайний виклик функції (він виконує деякі більш-менш складні операції, параметризовані аргументами), то я використовую синтаксис виклику звичайної функції.
• Для ініціалізації за замовчуванням я завжди використовую фігурні дужки.
  З одного боку, таким чином я завжди впевнений, що об'єкт ініціалізується незалежно від того, наприклад, це "реальний" клас із конструктором за замовчуванням, який би називався так чи інакше або вбудованим / POD-типом. По-друге, це - у більшості випадків - відповідає першому правилу, оскільки ініціалізований за замовчуванням об'єкт часто представляє "порожній" об'єкт.

На мій досвід, цей набір правил можна застосовувати набагато послідовніше, ніж використання фігурних дужок за замовчуванням, але потрібно чітко пам’ятати всі винятки, коли вони не можуть бути використані або мають інше значення, ніж «нормальний» синтаксис виклику функцій із дужками (викликає різну перевантаження).

Наприклад, вона добре поєднується зі стандартними типами бібліотек, як 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

Є багато причин для ініціалізації використання розпірки, але ви повинні знати , що конструктор найкращим за всі інші конструктори , виняток становить за замовчуванням, конструктор. Це призводить до проблем з конструкторами та шаблонами, де конструктор типу може бути списком ініціалізатора або простим старим 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!!!
}

Якщо припустити, що ви не стикаєтеся з такими класами, є мало причин не використовувати список інсталайзера.

Це безпечніше лише до тих пір, поки ви не будете створювати з-за-звуження, як, наприклад, Google у Chromium. Якщо ви це зробите, то МЕНШЕ безпечно. Без цього прапора лише C ++ 20 буде виправлено лише небезпечні випадки.

Примітка: А) фігурні дужки безпечніші, оскільки не допускають звуження. B) Кучеряві брекери менш безпечні, оскільки можуть обходити приватні або видалені конструктори та викликати явні позначені конструктори неявно.

Ці дві комбіновані засоби означають, що вони безпечніші, якщо всередині є примітивні константи, але менш безпечні, якщо вони є об'єктами (хоча вони зафіксовані в C ++ 20)