Welche Ausgabe erwartet ihr?

Belli

Arcoth schrieb:

Die Frage war warum das der Fall ist.

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

TNA

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.

Skym0sh0

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 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.

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::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.

Columbo

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.

Belli

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.

Columbo

"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.

TNA

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.

volkard

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.

Skym0sh0

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.

Swordfish

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-list nimmt.

Er würde also nie-nicht etwas schreiben wie

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

.

Columbo

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

Und was ist mit Aggregat-Initialisierungen?

volkard

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 {};
}

volkard

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{})>*);

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

Swordfish

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 )();
}