Abstrakte Klassen, Vererbung, Referenzen und Parameterügergabe
-
Also ich bin jetzt aber doch der Meinung, dass die Klasse im gleichen Namespace wie ihre Methoden liegen muss - sonst klappt doch der Lookup schon garnicht mehr...
-
Phoemuex schrieb:
Achso, dann habe ich dich zuerst falsch verstanden.
Dafür gibt es drei "Möglichkeiten"
- Wieso sollte man das wollen, was du willst, wenn es anders doch auch, besser und ohne Mehraufwand geht?
Falls man es doch unbedingt machen will:
Danke.
Hm, war mir nicht sicher, ob das in C++ immer noch so gemacht wird mit Header- und Sorucedatei, oder ob das nur in C so sein sollte und in C++ andere Konventionen gelten. Hab kein größeres Problem damit immer 2 Files anzulegen.
-
Phoemuex schrieb:
- Anonyme Namespaces benutzen
dann muss auch die klasse im anonymen namespace sein - und dann handelt es sich nicht mehr um eine mehrfache definition derselben klasse (bzw. deren memberfunktionen) in mehreren ÜEs (die sind höchtens layout-komaptibel).
-
Ähm, also wegen dem nicht funktionieren:
Ich habe das mit dem Compiler, der bei Code::Blocks dabei ist genauso wie im Beispiel geschrieben und das Programm ließ
- sich kompilieren
- linken
- lief auch mit der erwarteten Ausgabe...
Kann aber halt sein, dass es trotzdem nicht Standard-konform ist...
-
also vc++8.0 hat schon mal was dagegen. und wenn ich ein bisschen stöbere finde ich bestimmt auch eine aussage im standard, die dieses verhalten unterstützt oder sogar verlangt. übrigens hast du es in diesem beispiel ja noch nicht mit mehreren ÜEs zu tun. funktioniert das linken dann immer noch ?
-
da wäre z.b. 9.3/2
A member function may be defined (8.4) in its class definition, in which case it is an inline member function (7.1.2), or it may be defined outside of its class definition if it has already been declared but not defined in its class definition. A member function definition that appears outside of the class definition shall appear in a namespace scope enclosing the class definition. Except for member function definitions that appear outside of a class definition, and except for explicit specializations of member functions of class templates and member function templates (14.7) appearing outside of the class definition, a member function shall not be redeclared.
-
Ok, ich sehs ein, ich hab ja auch direkt geschrieben, dass ich mir nicht sicher bin:
Phoemuex schrieb:
Bei dieser Methode bin ich mir aber nicht sicher, ob das wirklich immer so toll funktioniert, die ist mir gerade nur eingefallen
Aber weils sich (bei mir) kompilieren ließ, habe ich halt gedacht, ich poste es mal
-
Hallo nochmals,
also nach der Trennung in Header und Source Dateien klappts nun mit dem Kompilieren.
Gewundert hat es mich aber, dass ich für die pure virtual Methode destroy() auch eine Implementierung in der abstrakten Basisklasse angeben musste?!
Ich dachte, man muss nur für eine pure virtual Methode ne Implementierung angeben, nicht für alle?Ciao
-
ob eine funktion implementiert werden muss, hängt davon ab, ob sie von irgendwoher referenziert wird. prinzipiell muss keine deklarierte funktion (ob nun pure virtuell oder nicht) implementiert werden, solange sie nicht aufgerufen wird. in diesem speziellen fall ist das sogar undefiniertes verhalten. da bin ich doch erst vor ein paar tagen drüber gestolpert:
nochmal abstrakte klassen
-
OK, das leuchtet ein!
destroy() wird im Destruktor der Klasse gerufen!Die pure virtual Methoden müssen aber dennoch immer überschrieben werden, wenn die abgeleiteten Klassen nicht abstrakt sein sollen, auch wenn sie schon ne Implementierung in der Basisklasse haben, oder?
-
Reth schrieb:
OK, das leuchtet ein!
destroy() wird im Destruktor der Klasse gerufen!Die pure virtual Methoden müssen aber dennoch immer überschrieben werden, wenn die abgeleiteten Klassen nicht abstrakt sein sollen, auch wenn sie schon ne Implementierung in der Basisklasse haben, oder?
richtig. allerdings rufst du hier die funktion aus dem destruktor der basisklasse auf, und in diesem falle hast du eben ein problem, wie im anderen thread beschrieben.