linker-Fehler bei abstraktem virtuellen Dtor
-
Shade Of Mine schrieb:
Mir kommt es so vor, als würden meine Beiträge hier nicht genau gelesen werden.
Ganz genau.
Sorry, sah auf die schnelle so aus als wäre der Code nur zur Unterstreichung der Aussage "entweder körper oder =0" gemeint.
-
class foo { public: virtual ~foo()=0; virtual void x()=0; }; foo::~foo() {} // wenn foo::~foo() nicht implementiert ist => link-fehler // macht für mich sinn da automatisch von abgeleiteten klassen aufgerufen void foo::x() {} // pure virtual aber trotzdem implementiert ( das war neu für mich ) class bar :public foo { public: //virtual ~bar(){} // muss nicht implementiert werden obwohl foo::~foo() als pure virtual deklariert ??? // andererseits macht es auch keinen sinn die implementation eines dtor's zu erzwingen. // welchen sinn macht dann die decl virtual ~foo()=0; ???? // oder ist das ein bug in meinem compiler (g++) virtual void x(); }; void bar::x() { // das macht sinn ich bin gezwungen die methode bar::x() zu implementieren, // kann aber die implementation von foo::x() verwenden foo::x(); } int main() { bar t; }
-
finix schrieb:
#include <iostream> class Foo { public: virtual void whatever() = 0; }; class Bar : public Foo { public: virtual void whatever(); }; void Foo::whatever() { std::cout << "world!\n"; } void Bar::whatever() { std::cout << "hello\n"; Foo::whatever(); } int main() { Bar test; test.whatever(); }
aber was soll das bringen? das widerspricht ja dem "konzept" von solchen funktionen (func() = 0;) -> sollen eigentlich eine einheitliche schnittstelle darstellen; die eigentlichen implementationen sollen die abgeleiteten klassen "übernehmen"
-
Lars Hupel schrieb:
aber was soll das bringen? das widerspricht ja dem "konzept" von solchen funktionen (func() = 0;) -> sollen eigentlich eine einheitliche schnittstelle darstellen; die eigentlichen implementationen sollen die abgeleiteten klassen "übernehmen"
Nein, es widerspricht nicht.
Denn =0 heisst: abgeleitete Klasse muss es implementieren.
nun kann in Base aber dennoch sinnvolle 'hilfs funktionalität' implementiert sein. zB am beispiel von Java -> die clone Methode.
In C++ könnte man das mit einer rein virtuellen Methode clone() machen. Die abgeleitete Klasse muss clone() definieren aber dennoch Base::clone() aufrufen, weil ja auch Base geklont werden will. So hat man dann in Object eine rein virtuelle clone Methode mit einem Körper.
Da widerspricht sich nichts.
-
Ich frag mich was die jetzige Diskussion soll. AFAIK benötigt nur ein rein virtueller Destruktor einen Körper. Andere rein virtuelle Funktionen nicht, obwohl es natürlich nicht verboten ist einen zu erzeugen.
Ein rein virtueller Destruktor ist auch nur dann nötig, wenn man die Klasse abstrakt machen will und keine anderen Funktionen zur Verfügung stehen.
-
Braunstein schrieb:
Ich frag mich was die jetzige Diskussion soll. AFAIK benötigt nur ein rein virtueller Destruktor einen Körper. Andere rein virtuelle Funktionen nicht, obwohl es natürlich nicht verboten ist einen zu erzeugen.
Ein rein virtueller Destruktor ist auch nur dann nötig, wenn man die Klasse abstrakt machen will und keine anderen Funktionen zur Verfügung stehen.wenn das wirklich so wäre würde das ganze für mich sinn machen, aber zumindest bei g++ bin ich nicht gezwungen einen rein virtuellen dtor in abgeleiteten klassen zu implementieren, also wird die klasse auch nicht rein abstrakt. ( siehe mein voriges posting )
Kurt.
-
Du vergisst, das in deinem Fall der Compiler automatisch einen default Destruktor in der abgeleiteten Klasse erstellt.
-
genau, also was habe ich dann von einem pure virtual Dtor? Es wird automatisch in der abgeleiteten Klasse ein Dtor erstellt (muß ja auch). Ich sehe da im Moment keinen Unterschied zum virtuellen Dtor
.
-
TheBigW schrieb:
genau, also was habe ich dann von einem pure virtual Dtor? Es wird automatisch in der abgeleiteten Klasse ein Dtor erstellt (muß ja auch). Ich sehe da im Moment keinen Unterschied zum virtuellen Dtor
.
Der Sinn wurde bereits erklärt. Ein rein virtueller Destruktor ist dann sinnvoll, wenn du eine abstrakte Klasse erzeugen willst, du aber keine andere rein virtuelle Funktion hast. Z.B. weil alle deine virtuellen Funktionen eine sinnvolle Default-Implementierung haben und diese auch per später Bindung aufrufbar sein sollen.
-
@ HumeSikkins: inwieweit ist eine solche klasse abstrakt, ich merke ja nur in der decl. dass sie abstrakt definiert wurde, das hat aber sonst keine auswirkungen ( ich bin nicht gezwungen irgend etwas in abgeleiteten klassen zu implementieren ) ??
Kurt
-
Es dreht sich hier doch nicht um die abgeleitete Klasse. Die Basisklasse ist abstrakt und das sollte damit auch bezweckt werden.
-
Hab's gerade herausgefunden, jetzt macht alle sinn.
K.
-
Stimmt. Liegt daran, das ich abstrakte Klassen immer dafür verwendet habe, damit jemand, der davon ableitet und vergißt etwas virtuelles selbst zu implementieren vom Compiler angemeckert wird - das trift ja beim pure virtual Dtor nicht zu.
Das merkt er erst, wenn man versucht die Klasse zu instanziieren (ich übrigens auch, deshalb die Frage:)).Danke @all für diesen Thread