Struct Konstruktor

Columbo

Nexus schrieb:

P.S.: Tritt jemand den Verfechtern von enum struct statt enum class bei?

Wenns schon 2 Varianten gibt, kann man sie für semantische Unterschiede einsetzen. Ich nehme struct meist für kleine Datenbündel oder Funktoren und class für Klassen mit Kapselung.

So ist es bei mir und bei vielen anderen auch. Das sollte man nicht dazu missbrauchen, weniger private oder public zu schreiben.

Nexus

Trotzdem hätte man sich ohne Probleme auf typename für Template-Typparameter festlegen können. Ist ja nicht so, dass class irgendeinen Vorteil (vielleicht abgesehen von Kompatibilität in der Steinzeit) brächte. Sogar der ursprüngliche Punkt, dass Template-Templates class erfordern, weil es sich um Klassen handeln muss, dürfte mit Template Aliases dahin sein. Was bleibt, ist ein weiteres Relikt, an dessen Ursprung sich niemand mehr erinnern kann. Wie <iosfwd> neulich. Oder in nicht allzu ferner Zukunft Disketten als Speichern-Icon.

Es gibt aber genügend solche fast gleichen Sachen. Und das kann man keineswegs nur auf C oder antikes C++ schieben; auch C++11 schreckt nicht davor zurück, subtilste Falltüren einzubauen: decltype mit und ohne Zusatzklammern, int&& vs T&& als Parameter. Scheint tief in der Sprachphilosophie verankert zu sein.

Auch von mehreren Schreibweisen für genau das Gleiche gibts einige zunächst unintuitive Sachen: int* und int x[3] als Parameter, &func und func für Funktionszeiger, Dutzende typedef s für Ganzzahlen in der Standardbibliothek. Alles auch mehr verwirrend als nützlich.

Und vergessen wir nicht gleiche Schreibweise für Verschiedenes, an vorderster Front Most Vexing Parse. Oder die "Uniform Initialization", erst mit ihr kann die Schreibweise X x = {args} einheitlicherweise sowohl Aggregat-Initialisierung, Konstruktoraufruf mit mehreren Parametern als auch Initializer-List bedeuten

Columbo

dürfte mit Template Aliases dahin sein

Alias-Templates. Das ist dasselbe Missverständnis wie "Template Klasse".

int&& vs T&& als Parameter

Nö! Das ist überhaupt nicht subtil. int&& ist ein feststehender Typ, wohingegen T&& - als Parameter - eine "Universal Reference" ist: Ein (ggf.) zu deduzierender Referenztyp. Es greift die reference-collapsing Regel. Es sind zwei von Grund auf verschiedene Dinge, ohne diese Regel wäre auch perfect forwarding nicht möglich.
Na gut, im Prinzip recht unintuitiv.

erst mit ihr kann die Schreibweise X x = {args} einheitlicherweise sowohl Aggregat-Initialisierung, Konstruktoraufruf mit mehreren Parametern als auch Initializer-List bedeuten

Das nennt sich einheitlich list-initialization, nennen wir es auf Deutsch fortan Listeninitialisierung. Diese gliedert sich völlig natürlich auf in eine Aggregatinitialisierung für Aggregate und Konstruktoraufrufe auf: Letzteres ist immer ein Konstruktoraufruf, nur dass bei diesem Konstruktoraufruf Initialisierungslisten-Konstruktoren in der Overload Resolution bevorzugt werden. Je nach dem werden die Elemente anders interpretiert, die Semantik ist aber insgesamt intuitiv.

Dutzende typedefs für Ganzzahlen in der Standardbibliothek.

Kannst du genau sagen, was an intmax_t , uint64_t , uint_fast64_t usw. verwirrend ist? Schaut man sich einmal die Definition an, wird schnell klar, wofür das nützlich ist.

So, ich gebe auf. Man kann C++ nicht verteidigen.

Nathan

hustbaer schrieb:

Öhm.
Ich würde nicht sagen dass das das selbe ist.

class vs. typename bei Templateparameters ist exakt das selbe von der Bedeutung her. "Subtil" ist dabei höchstens die Frage wo man statt typename auch class schreiben kann. Aber dort wo man class statt typename schreiben kann, bewirkt es exakt das selbe. Es sei denn ich hätte da irgend eine bekloppte C++11/14 Neuerung verpennt.

Also eher das selbe wie signed int vs. int .

BTW: char vs. signed char vs. unsigned char ist auch so ne komische C++ Sache.

Jetzt bin ich gerade verwiirt.

template <template <typename> class T>
class foo;

Geht soweit ich weiß nicht mit typename...

Columbo

Geht soweit ich weiß nicht mit typename...

Ja und? Was ist nun an hustbaers Beitrag verwirrend? Er sagt, wo man beide austauschen kann, sind sie identisch. Wo nicht, da nicht.