OOP mal wieder
-
Artchi schrieb:
Badestrand! Soweit fast richtig.
Hier wird ebend gerade nicht der Ctor aufgerufen:
Cl = new Cl; // KonstruktorInteresante Theorie. Wenn Du jetzt noch erklären könntest wie ein neues Objekte der Klasse Cl hier konstruiert werden soll _ohne_ einen Ctor aufzurufen...
-
Artchi schrieb:
Badestrand! Soweit fast richtig.
Hier wird ebend gerade nicht der Ctor aufgerufen:
Cl = new Cl; // KonstruktorHier schon:
Cl = new Cl(); // KonstruktorArtchi du enttäuscht mich zu tiefst!
-
Bei UDTs ist es vollkommen egal ob man "new UDT" oder "new UDT()" schreibt.
Der einzige Unterschied besteht bei eingebauten Typen, nämlich dass die zero-initialization weggelassen wird wenn man "new int" (ohne Klammern) schreibt. Was aber mit einem Konstruktor nixe nicht zu tun hat.
-
schue schrieb:
Sqwan schrieb:
gib mir nen link zu nem Tutorial wo das steht...
In denen die ich gelsen habe, steht das der konstruktor die variablen auf die grundwerte setzt...
Das er den selben namen haben muss steht das nicht...
Wo ihr es sagt fällts allerdings auf...
und auch in meinem c++ buch sind zwar alle konstruktor mit dem namen der klasse identisch... aber das das so sein muss steht da nicht...Zitat aus C++, die Programmiersprache, Seite 240 (KOnstruktoren): "Ein Konstruktor ist dadurch gekennzeichnet, daß er denselben Namen hat wie die zugehörige Klasse".
Manchmal hilft es wirklich die Standartwerke zu besitzen... Und sie auch zu lesen
Konstruktoren haben keine Namen (12.1/1). Es existiert lediglich eine spezielle Syntax, um sie - unter Verwendung des Klassennamens - zu deklarieren. Das gilt auch für Destruktoren. Der Standard macht sich hier gar nicht die Mühe, zu sagen, dass diese keine Namen haben; das folgt bereits aus ihrer Deklarationssyntax. ~T kann kein (gewöhnlicher) Name sein, denn es handelt sich lexikalisch um 2 Token.
hustbaer schrieb:
Bei UDTs ist es vollkommen egal ob man "new UDT" oder "new UDT()" schreibt.
Der einzige Unterschied besteht bei eingebauten Typen, nämlich dass die zero-initialization weggelassen wird wenn man "new int" (ohne Klammern) schreibt. Was aber mit einem Konstruktor nixe nicht zu tun hat.Ob new T einen Konstruktor aufruft oder nicht hängt davon ab, ob T (bzw der Elementtyp, wenn T ein array ist) ein POD ist oder nicht. Zwar können (in deiesem Zusammenhang, wir ignorieren mal Referenzen) nur UDTs nicht-PODs sein, aber nicht jeder UDT ist nicht-POD.
-
camper schrieb:
schue schrieb:
Sqwan schrieb:
gib mir nen link zu nem Tutorial wo das steht...
In denen die ich gelsen habe, steht das der konstruktor die variablen auf die grundwerte setzt...
Das er den selben namen haben muss steht das nicht...
Wo ihr es sagt fällts allerdings auf...
und auch in meinem c++ buch sind zwar alle konstruktor mit dem namen der klasse identisch... aber das das so sein muss steht da nicht...Zitat aus C++, die Programmiersprache, Seite 240 (KOnstruktoren): "Ein Konstruktor ist dadurch gekennzeichnet, daß er denselben Namen hat wie die zugehörige Klasse".
Manchmal hilft es wirklich die Standartwerke zu besitzen... Und sie auch zu lesen
Konstruktoren haben keine Namen (12.1/1). Es existiert lediglich eine spezielle Syntax, um sie - unter Verwendung des Klassennamens - zu deklarieren. Das gilt auch für Destruktoren. Der Standard macht sich hier gar nicht die Mühe, zu sagen, dass diese keine Namen haben; das folgt bereits aus ihrer Deklarationssyntax. ~T kann kein (gewöhnlicher) Name sein, denn es handelt sich lexikalisch um 2 Token.
Ok, dann schreib doch gleich Bjarne ne email das er das in seinem Buch falsch dargestellt hat.
-
schue schrieb:
Ok, dann schreib doch gleich Bjarne ne email das er das in seinem Buch falsch dargestellt hat.
Erstmal schau ich mir das Ganze am WE (hab das Buch grad nicht zur Hand) im Original an, möglicherweise ist das Zitat auch unvollständig. Welches Kapitel ist das? Bei Widersprüchen hat der Text des Standards allerdings grundsätzlich Vorrang vor irgendwelchen externen Quellen, selbst wenn sie von Stroustrup stammen.
ISO/IEC 14882:2003 schrieb:
12.1 Constructors [class.ctor]
1 Constructors do not have names.Da ist einfach kein Interpretationsspielraum.
-
wenn konstruktoren keinen namen haben, wie erklärt sich dann die implementierungssyntax Klasse::Klasse(){}? auch als spezielles schlagwort?
halte den auszug aus der ISO für daneben. klar haben konstruktoren einen namen, der sogar sehr wohl definiert ist.
-
Tut mir leid, aber einen Namen (für den Ctor), der 100% mit dem der Klasse übereinstimmen muss, kann ich beim besten Willen nicht als eigenen Namen ansehen. Demnach würde ich doch eher der Aussage des Standards folgen, dass Konstruktoren keinen Namen haben...
Man könnte natürlich auch definieren dass ein Konstruktor als Namen den der Klasse hat (was ihn aber als "Eigennamen" im Sinne des Wortes disqualifiziert, weil er eben nicht frei definierbar ist). Was aber exakt aufs selbe hinausläuft.
Worum geht's hier eigentlich?
-
wtf schrieb:
Artchi schrieb:
Badestrand! Soweit fast richtig.
Hier wird ebend gerade nicht der Ctor aufgerufen:
Cl = new Cl; // KonstruktorHier schon:
Cl = new Cl(); // KonstruktorArtchi du enttäuscht mich zu tiefst!
Stell dir vor, ich bin auch nur ein Mensch!
-
thordk schrieb:
wenn konstruktoren keinen namen haben, wie erklärt sich dann die implementierungssyntax Klasse::Klasse(){}? auch als spezielles schlagwort?
Das wurde bereits dargestellt, aberr bitte:
ISO/IEC 14882:2003 schrieb:
12.1 Constructors [class.ctor]
1 Constructors do not have names. A special declarator syntax using an optional sequence of functionspecifiers (7.1.2) followed by the constructor’s class name followed by a parameter list is used to declare or define the constructor.Der Standard spricht grundsätzlich und konsistent nur vom "constructor's class name". Im Übrigen ist die Annahme eines Namens für Konstruktoren noch aus einem anderen Grunde irrig. Sie würde das name lookup aushebeln. Da der Name einer Klasse in ihren Namensraum "injiziert" wird (9/2 Satz 2) hätten wir dann plötzlich den Namen eines Typs als auch eine (möglicherweise überladene) Funktion gleichen Namens im selben Scope. Diese Möglichkeit ist in der Aufzählung von 3.3/4 aber nicht enthalten.
halte den auszug aus der ISO für daneben. klar haben konstruktoren einen namen, der sogar sehr wohl definiert ist.
Du darfst davon halten, was du willst. Was nun normativ ist oder nicht, wird von deiner Haltung nicht bestimmt.
-
Es gibt sowas wie einen Unterschied zwischen einer technischen Spezifikation und dem Sprachgebrauch. Sicher stimmt es das ein Ctor keinen Namen im Sinne einer Funktion haben mag, aber wie soll ich denn in Zukunft folgenden Satz bilden, wenn ich versuche einem Anfänger zu erklären das der CTor den gleichen Namen wie die Klasse haben muß?
Der [Zeichenkette die identisch mit dem Klassennamen ist] des CTors muß identisch mit dem Klassennamen sein.
Vorschläge bitte...
Gleichermassen verwissrend dürfte dann folgender Satz ausfallen: Der CTor hat keinen Namen muß aber nach der Klasse benannt werden.
-
schue schrieb:
Es gibt sowas wie einen Unterschied zwischen einer technischen Spezifikation und dem Sprachgebrauch. Sicher stimmt es das ein Ctor keinen Namen im Sinne einer Funktion haben mag, aber wie soll ich denn in Zukunft folgenden Satz bilden, wenn ich versuche einem Anfänger zu erklären das der CTor den gleichen Namen wie die Klasse haben muß?
Das kannst du ja so tun, aber dann bitte nicht mit Zitaten von Stroustrup kommen, die den Anschein des Autoritären haben. Es genügt ja nicht, in einer Erklärung zu sagen, der Kontruktor hat den Namen der Klasse. Irgenwie muss da noch hin, dass kein Rückgabewert existiert - trotzdem schreiben wir kein void dahin. Es ist also sowieso eine spezielle Syntax gegeben. Und wenn wir statt dessen sagen, dass die Deklaration einer speziellen Syntax folgt, brauchen wir das Vehikel des Namens eigentlich von vornherein nicht.
-
"Der Konstruktor hat immer den Namen der Klasse und besitzt keinen Rueckgabetyp (auch nicht void)" --> ist doch ne gute Erklaerung fuer Anfaenger. leicht verstaendlich, leicht anwendbar. Dass der Standard das anders erklaert kann ja dann im spaeteren Verlauf erklaert werden.
Jedenfalls fand ich eine solche Erklaerung als ich zum ersten Mal etwas von Konstruktor gehoert habe einleuchtend und hatte keine Probleme in der Anwendung.
-
Shinja schrieb:
"Der Konstruktor hat immer den Namen der Klasse und besitzt keinen Rueckgabetyp (auch nicht void)" --> ist doch ne gute Erklaerung fuer Anfaenger....
Aber nur solange, bis der Anfänger dazu kommt, was mit "Name" alles gemeint ist und gemacht wird ("name lookup", ....) ... spätestens dann muß er reinfallen und nochmal umlernen.
Bei all den Ausnahmen (Konstruktoren werden auch nicht "vererbt" wie andere Methoden, werden bisweilen automatisch generiert und aufgerufen, sollten keine virtuellen Funktionen aufrufen, ....) wird der Sinn der Regel "Wie eine Funktion, außer ...." immer dünner.
Konstruktoren sind einfach besondere Konstrukte, mit denen man sich besonders beschäftigen muß.
Gruß,
Simon2.
-
Anonymous schrieb:
Noch vor fünf Jahren hätte ich auch der Aussage zugestimmt, daß man halt kleine Projekte ebenso gut in C schreiben kann, größere Sachen dann in C++. ...
Interessanetrweise hat mich gerade ein einjähriger (beruflich bedingter) Ausflug in C# dazu gebracht über meinen C++ Stil nachzudenken....Ich würde sagen: Es kommt nicht auf die Länge an !
Entscheidend für die Wahl des Paradigmas ist die Struktur der Aufgabenstellung. Es gibt Aufgaben, die können nicht besser als prozedural beschreiben werden ... und da sollte man auch prozedural programmieren. Ein "Mischmasch" klingt abwertender, als es ist .... ich würde einfach davon sprechen, dass prozedurale und "oo-tierte" Aufgaben ineinandergreifen.
Es ein gleich großer Krampf,
- in einem Umfeld mit sehr vielen voneinander unabhängigen "Komponenten" prozedural zu programmieren wie
- für eine algorithmisch angelegte Aufgabe säckeweise interagierende Klassen anzulegen.Natürlich neigen "größere Sachen" eher dazu, viele Abhängigkeiten und Komponenten zu haben und "kleinere Sachen" verzeihen eher eine unscharfe Kapselung, aber das sind IMO nur Begleiterscheinungen/Hinweise und nicht Hauptkriterien.
my2c
Gruß,
Simon2.
