Was sind die Vorteile der Listeninitialisierung (mit geschweiften Klammern)?

Question 1

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

Wieso den?

Question 2

Grundsätzlich Kopieren und Einfügen von Bjarne Stroustrup “Die Programmiersprache C++ 4. Auflage”:

Listeninitialisierung erlaubt keine Einengung (§iso.8.5.4). Das ist:

Eine Ganzzahl kann nicht in eine andere Ganzzahl konvertiert werden, die ihren Wert nicht halten kann. Beispielsweise ist char to int erlaubt, aber nicht int to char.

Ein Gleitkommawert kann nicht in einen anderen Gleitkommatyp konvertiert werden, der seinen Wert nicht halten kann. Float-to-Double ist beispielsweise erlaubt, aber nicht double-to-float.
Ein Gleitkommawert kann nicht in einen ganzzahligen Typ konvertiert werden.
Ein ganzzahliger Wert kann nicht in einen Fließkommatyp konvertiert werden.

Beispiel:

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)

}

Das nur Situation, in der = gegenüber {} bevorzugt wird, wenn verwendet wird auto Schlüsselwort, um den vom Initialisierer bestimmten Typ abzurufen.

Beispiel:

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

Fazit

Bevorzugen Sie die {}-Initialisierung gegenüber Alternativen, es sei denn, Sie haben einen triftigen Grund, dies nicht zu tun.

Question 3

Es gibt bereits tolle Antworten zu den Vorteilen der Listeninitialisierung, aber meine persönliche Faustregel ist, möglichst keine geschweiften Klammern zu verwenden, sondern es von der konzeptionellen Bedeutung abhängig zu machen:

Wenn das Objekt, das ich erstelle, konzeptionell die Werte enthält, die ich im Konstruktor übergebe (z. B. Container, POD-Strukturen, Atomic, intelligente Zeiger usw.), verwende ich die geschweiften Klammern.
Wenn der Konstruktor einem normalen Funktionsaufruf ähnelt (er führt einige mehr oder weniger komplexe Operationen aus, die durch die Argumente parametrisiert werden), verwende ich die normale Funktionsaufrufsyntax.
Für die Standardinitialisierung verwende ich immer geschweifte Klammern.
Zum einen bin ich mir so immer sicher, dass das Objekt initialisiert wird, egal ob es sich zB um eine “echte” Klasse mit einem Default-Konstruktor handelt, der sowieso aufgerufen würde, oder um einen eingebauten / POD-Typ. Zweitens ist es – in den meisten Fällen – konsistent mit der ersten Regel, da ein standardmäßig initialisiertes Objekt oft ein “leeres” Objekt darstellt.

Meiner Erfahrung nach kann dieser Regelsatz viel konsistenter angewendet werden, als standardmäßig geschweifte Klammern zu verwenden, sich aber alle Ausnahmen explizit merken zu müssen, wenn sie nicht verwendet werden können oder eine andere Bedeutung haben als die “normale” Funktionsaufrufsyntax mit Klammern (ruft eine andere Überladung auf).

Es passt zB gut zu Standard-Bibliothekstypen wie 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

Question 4

Es gibt VIELE Gründe, die Klammerinitialisierung zu verwenden, aber Sie sollten sich dessen bewusst sein das initializer_list<> Konstruktor wird den anderen Konstruktoren vorgezogen, wobei die Ausnahme der Standardkonstruktor ist. Dies führt zu Problemen mit Konstruktoren und Vorlagen, bei denen der Typ T Konstruktor kann entweder eine Initialisierungsliste oder ein einfacher alter Ctor sein.

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

Angenommen, Sie begegnen solchen Klassen nicht, gibt es wenig Grund, die Initialisiererliste nicht zu verwenden.

Question 5

Es ist nur sicherer, solange Sie nicht mit -Wno-narrowing bauen, wie es beispielsweise Google in Chromium tut. Wenn Sie dies tun, ist es WENIGER sicher. Ohne dieses Flag werden die einzigen unsicheren Fälle jedoch von C++20 behoben.

Hinweis: A) Geschweifte Klammern sind sicherer, da sie keine Verengung zulassen. B) Geschweifte Klammern sind weniger sicher, da sie private oder gelöschte Konstruktoren umgehen und explizit markierte Konstruktoren implizit aufrufen können.

Diese beiden Kombinationen bedeuten, dass sie sicherer sind, wenn es sich bei dem Inhalt um primitive Konstanten handelt, aber weniger sicher, wenn es sich um Objekte handelt (obwohl in C++20 behoben).

Question 6

Update (11.02.2022): Beachten Sie, dass es zu diesem Thema neuere Meinungen als die ursprünglich gepostete (unten) gibt, die gegen die Bevorzugung des {}-Initialisierers argumentieren, wie Arthur Dwyer in seinem Blogbeitrag on Der Knightmare der Initialisierung in C++.

Ursprüngliche Antwort:

Lesen Herb Sutters (aktualisiert) GotW #1. Dies erklärt im Detail den Unterschied zwischen diesen und einigen weiteren Optionen, zusammen mit einigen Fallstricken, die für die Unterscheidung des Verhaltens der verschiedenen Optionen relevant sind.

Das Wesentliche / kopiert aus Abschnitt 4:

Wann sollten Sie ( ) vs. { } Syntax verwenden, um Objekte zu initialisieren? Wieso den? Hier ist die einfache Richtlinie:

Richtlinie: Bevorzugen Sie die Initialisierung mit { }, z. B. Vektor v = { 1, 2, 3, 4 }; oder auto v = vector{ 1, 2, 3, 4 };, weil es konsistenter und korrekter ist und es vermeidet, sich überhaupt mit Fallstricken im alten Stil auskennen zu müssen. In Fällen mit einem Argument, in denen Sie lieber nur das =-Zeichen sehen möchten, wie z. B. int i = 42; und auto x = irgendetwas; das Weglassen der Klammern ist in Ordnung. …

Damit sind die meisten Fälle abgedeckt. Es gibt nur eine Hauptausnahme:

… In seltenen Fällen wie Vektor v(10,20); oder auto v = vector(10,20);, verwenden Sie die Initialisierung mit ( ), um explizit einen Konstruktor aufzurufen, der andernfalls durch einen initializer_list-Konstruktor verborgen wird.

Der Grund, warum dies jedoch im Allgemeinen „selten“ sein sollte, liegt darin, dass Standard- und Kopierkonstruktion bereits etwas Besonderes sind und gut mit { } funktionieren, und gutes Klassendesign vermeidet aus diesem Grund jetzt meistens den Rückgriff auf ()-Fall für benutzerdefinierte Konstruktoren endgültige Designrichtlinie:

Richtlinie: Vermeiden Sie beim Entwerfen einer Klasse die Bereitstellung eines Konstruktors, der mehrdeutig mit einem initializer_list-Konstruktor überladen wird, damit Benutzer nicht ( ) verwenden müssen, um einen solchen versteckten Konstruktor zu erreichen.

Siehe auch die Kernrichtlinien zu diesem Thema: ES.23: Bevorzugen Sie die {}-Initialisierer-Syntax.