@Mods: Diesen Thread von blurry müsstet ihr jetzt nicht unbedingt löschen.

SeppJ hatte mit dem Auslotungsprozess leider völlig Recht.

@Nathan: Keiner hat Lust blurry hier eine adäquate Antwort zu geben, auch dot trollt nur rum - und das obwohl die Frage erstaunlich gut ist und im Forum noch gar nicht behandelt wurde (AFAIR).

SeppJ hatte mit dem Auslotungsprozess leider völlig Recht.

Ok, das musst du mir jetzt erklären, wo genau trolle ich bitte rum? Die Frage seh ich hier iirc nicht zum ersten Mal und selbst der Wikipedia Artikel sowie so ziemlich jedes Beispiel zum entsprechenden Sprachfeature, das ich je gesehen hab, geht sogar auf exakt das Problem hier ein...

wo genau trolle ich bitte rum?

Du hast praktisch genau das ausgesagt was schon längst jeder (einschließlich blurry) wissen musste: Das nämlich der erste vector ein, der zweite aber zwei Elemente hat. Das ist ja auch genau das was die Ausgabe uns so offenkundig verrät. Die Frage war warum das der Fall ist. Da du redundanterweise etwas völlig offensichtliches erklärt hast, kam für mich dein Beitrag als Getrolle an.

Mit "erstaunlich gut" meinte ich hier auch eigentlich "erstaunlich gut für blurrys Verhältnisse". Natürlich wurde die Frage schon huntertmal durchgekaut und dient als das Standardbeispiel um Schwächen von uniform initialization aufzuzeigen. Dennoch kann ich mich noch nicht an einen Thread erinnern der sich um genau diesen konkreten Fall gehandelt hat.

wo genau trolle ich bitte rum?

Du hast praktisch genau das ausgesagt was schon längst jeder (einschließlich blurry) wissen musste: Das nämlich der erste vector ein, der zweite aber zwei Elemente hat. Das ist ja auch genau das was die Ausgabe uns so offenkundig verrät. Die Frage war warum das der Fall ist. Da du redundanterweise etwas völlig offensichtliches erklärt hast, kam für mich dein Beitrag als Getrolle an.

Ok, das macht Sinn; da ich die Antwort kannte, hab ich wohl zu viele Gedankensprünge auf einmal gemacht . Ich dachte, wenn ich darauf hinweise, dass die beiden Varianten offenbar zu Vektoren mit unterschiedlicher Anzahl an Elementen führen, würde ein Licht aufgehen...

Die Frage war warum das der Fall ist.

Welche Frage soll das gewesen sein?
Blurrys Frage lautete: "Welche Ausgabe erwartet ihr?"

Das Interface von Vector ist seit Einführung von initializer_list kaputt. Das lies sich leider nachträglich nicht ändern.

Wieso das? Das Program macht doch genau das was es soll.

D.h.

Foo f(a, b);
Foo g{a, b};

sollen dasselbe bedeuten und ausdrücken.

Und wie ists beim vector?

std::vector<float> a(5, 3);
std::vector<float> a{5, 3};

std::vector<int> a(5, 3);
std::vector<int> a{5, 3};

In beiden (d.h. 4) Fällen sollte durch Uniform initialization jeweils ein Vector mit 5 Elementen die 3 sind erzeugt werden. Aber was kommt raus?

Ja? Uniform Initialization ist dafür da, dass alle Initialisierungen gleich aussehen.

D.h.

Foo f(a, b);
Foo g{a, b};

sollen dasselbe bedeuten und ausdrücken.

Und wie ists beim vector?

std::vector<float> a(5, 3);
std::vector<float> a{5, 3};

std::vector<int> a(5, 3);
std::vector<int> a{5, 3};

In beiden (d.h. 4) Fällen sollte durch Uniform initialization jeweils ein Vector mit 5 Elementen die 3 sind erzeugt werden. Aber was kommt raus?

Die Ausgabe ist bei mir ist:

5 2
5 2

Ich verstehe worauf du hinaus willt. Ich habe bisher die Uniform initialization nicht benutzt. Man wuerde das gleiche Ergebnis erwarten. Aber der eine Aufruf ist ein expliziter Konstruktor Aufruf mit zwei Argumenten und der andere ein Aufruf mit einer initializer list.
Und dann gilt folgendes (von StackOverflow kopiert) oder? :

When objects of non-aggregate class type T are list-initialized (8.5.4), overload resolution selects the constructor in two phases:

— Initially, the candidate functions are the initializer-list constructors (8.5.4) of the class T and the argument list consists of the initializer list as a single argument.

— If no viable initializer-list constructor is found, overload resolution is performed again, where the candidate functions are all the constructors of the class T and the argument list consists of the elements of the initializer list.

In beiden (d.h. 4) Fällen sollte durch Uniform initialization jeweils ein Vector mit 5 Elementen die 3 sind erzeugt werden. Aber was kommt raus?

Wieso? std::vector hat einen Konstruktor, der eine std::initializer_list annimmt (siehe http://en.cppreference.com/w/cpp/container/vector/vector).
Verstehe ich vielleicht nicht was du suggerieren möchtest?

M.M.n. ist es eine Sauerei die Uniform Initialization für Konstruktoraufrufe von non-POD-Typen zu verwenden weil das Verhalten vom Code davon abhängig ist, ob ein std::initializer_list -Konstruktor definiert ist.

Blurrys Frage lautete: "Welche Ausgabe erwartet ihr?"

Ja, aber es ist klar dass er die Ausgabe nicht verstanden hat. Folglich braucht er eine Erklärung. Ich glaube kaum dass es ihm weiterhilft wenn wir ihm einfach sagen dass wir 12 erwarten. Ich denke du bist in diesem Forum um zu helfen, dann müsstest du auch wissen dass man nicht immer akribisch genau nur die Fragen beantwortet die der TE auch explizit hinschreibt.

"Meine Glaskugel ist gerade zur Reparatur".

Hier stellt nun mal einer eine klare Frage, da versuche ich nicht, irgendetwas anderes hineinzuinterpretieren.

"Meine Glaskugel ist gerade zur Reparatur".

Das sagen wir wenn der Code oder der Fehler (bzw. die Fehlermeldung) nicht gepostet wurde, Dinge die wir nicht erraten können.

M.M.n. ist es eine Sauerei die Uniform Initialization für Konstruktoraufrufe von non-POD-Typen zu verwenden weil das Verhalten vom Code davon abhängig ist, ob ein std::initializer_list -Konstruktor definiert ist.

Ich würde sagen, dass es bad practise ist, sowohl einen std::initializer_list -Konstruktor anzubuieten als auch einen Konstruktor mit zwei Argumenten vom selben Typ.

Ja? Uniform Initialization ist dafür da, dass alle Initialisierungen gleich aussehen.

Da hab ich es einfacher. Bei mir sind sie dazu da, Container initial zu befüllen.

Skym0sh0 schrieb:

Ja? Uniform Initialization ist dafür da, dass alle Initialisierungen gleich aussehen.

Da hab ich es einfacher. Bei mir sind sie dazu da, Container initial zu befüllen.

Da du mich ja eh immer berichtigst, dann mach es wenigstens auch hier.
Hab ich Uniform Initialization falsch verstanden, oder wie?

Oder ists wieder einer deiner Trollposts und du meinst eigentlich Initializer Lists?

Skym0sh0 schrieb:

Ja? Uniform Initialization ist dafür da, dass alle Initialisierungen gleich aussehen.

Da hab ich es einfacher. Bei mir sind sie dazu da, Container initial zu befüllen.

So handhabe ich das auch.

std::vector< int > foo( 2, 0 );

wenn er klarstellen will, daß kein Konstruktor aufgerufen wird, der eine initializer-list nimmt.

Er würde also nie-nicht etwas schreiben wie

for( unsigned i{}; i < MAX; ++i );

.

Bei mir sind sie dazu da, Container initial zu befüllen.

Und was ist mit Aggregat-Initialisierungen?

Er würde also nie-nicht etwas schreiben wie

for( unsigned i{}; i < MAX; ++i );

.

Genau!

Überlegen muss ich mir noch

auto main(void) -> int {
	…
	return {};
}

Bei mir sind sie dazu da, Container initial zu befüllen.

Und was ist mit Aggregat-Initialisierungen?

Ja, es gibt Ausnahmen.

Nach Möglichkeit wünsche ich mir für structs auch normale Konstruktoren.

Ich nenne mal

static YesType Check(SizeToType<sizeof(U{})>*);

in
http://www.c-plusplus.net/forum/327733