Welche Ausgabe erwartet ihr?
-
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
vectorein, 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.
-
Arcoth schrieb:
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
vectorein, 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...
-
Arcoth schrieb:
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.
-
TNA schrieb:
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.
-
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?
-
Skym0sh0 schrieb:
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 2Ich 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.
-
Skym0sh0 schrieb:
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::vectorhat einen Konstruktor, der einestd::initializer_listannimmt (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.
-
Interessante Sichtweise.
Bei vielen anderen Postings, wo die Frage weniger klar formuliert ist, das Ansinnen des TE aber recht deutlich herausgelesen werden kann, lese ich oft Antworten wie:"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.
-
Statist schrieb:
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.
-
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.
-
volkard schrieb:
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?
-
volkard schrieb:
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.

-
Volkard meint, er verwendet etwas, was wie ein Konstruktoraufruf aussieht
std::vector< int > foo( 2, 0 );wenn er klarstellen will, daß kein Konstruktor aufgerufen wird, der eine
initializer-listnimmt.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?
-
Swordfish schrieb:
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 {}; }
-
Arcoth schrieb:
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{})>*);
-
volkard schrieb:
Überlegen muss ich mir noch
auto main() -> int { … return {}; }Och, das ist doch ganz einfach:
#include <cstdlib> auto main() -> decltype( EXIT_SUCCESS ) { return decltype( EXIT_SUCCESS )(); }