ich möchte für meine abstrakte Basisklasse auch einen rein virtuellen Destruktor haben:

virtual ~MeinAbstraktesBasisObjekt() = 0;

Das findet der Linker nicht in Ordnung:
"undefined reference to MeinAbstraktesBasisObjekt::~MeinAbstraktesBasisObjekt()'"

Ich habe alle abgeleiteten Klassen mit Destruktoren versehen, aber
das hilft offenbar nicht weiter.

Was mach ich falsch? Was kann ich tun?

Danke,
Stimpy

grüße

wenn man eine Abtrakte Klasse möchte aber keine Methoden hat die rein virtuell sein dürfen

Nach dem Motto wenn schon sonst keiner abstrakt ist, dann wenigstens der Destruktor?

Meine Idee war eine andere. Ich möchte eine abstrakte Basisklasse, die momentan nur abstrakte Funktionen hat.
Mit dem virtuellen Destruktor möchte ich erzwingen, daß abgeleitete Objekte immer den richtigen Destruktor verwenden
(der eigentliche Sinn von virtuellen Destruktoren). Liege ich damit falsch?

Danke,
Stimpy

Wenn du andere abstrakte Methoden hast, brauchst du den virtuellen Desstructor nicht, da die Klasse sowieso nicht instanziert werden kann, und somit auch kein Destruktor nötig ist.
Lass ihn einfach weg

unsinn. abstrakte klassen treten natürlich als subobjekte auf, und sind als solche dann 'instanziert'. die antwort auf die frage ob virtueller destruktor oder nicht richtet sich einzig und allein danach, ob das betreffende objekt mittels delete auf einen zeiger auf diese abstrakte basisklasse zerstört werden soll, oder nicht (bzw. bei explizitem dtor-aufruf, ob statischer und dynamischer typ verschieden sein können). im übrigen hat jede klasse einen destruktor. wenn man ihn nicht selbst deklariert, macht der compiler das (public, und implementiert ihn auch, sofern die destruktoren der basisklassen/member aufrufbar sind). ein dtor ist virtuell, wenn er so deklariert wird, oder wenn ein dtor einer basisklasse virtuell ist.

Hmmm, zugegeben das klingt mir gerade selber etwas paranoid.
Aber nur weil ich paranoid bin, heißt das noch lange nicht,
daß sie nicht hinter mir her sind...

Geh mal zum Arzt wegen der Paranoia, oder lass das Kiffen ne Weile sein :p

Nein, es wird die ganze abgeleitete Klasse zerstört. Die abstrakte Basisklasse wird gar nie erzeugt, sie ist ja abstrakt.
Wenn du "pure virtual" Methoden hast, musst du die in jedem Fall in der abgeleiteten Klasse implementieren.
Ausserdem müssen Methoden nicht zerstört werden, nur Membervariablen

Unsinn.

stimpleton schrieb:

Wenn aber jemand anderes von meiner Klasse einiges ableitet und den virt. Destruktor vergißt, könnte ja nur die Hälfte zerstört werden.
Aber stimmt schon, das ist dann eigentlich dann sein Problem...

Das würde wegen der Default-Implementation ohnehin nicht funktionieren.

Ich kann ja nicht ahnen, wer mit welchen Zeigertypen auf welchen Ableitungen rumhantiert -> v.D. ist doch notwendig.

Aber die Default-Implementation fehlt ja, sonst würde der Linker nicht meckern.
Also gebe ich ihm eine leere Implementation, damit der zufrieden ist.
Damit sind dann alle glücklich?

Aber die Default-Implementation fehlt ja, sonst würde der Linker nicht meckern.
Also gebe ich ihm eine leere Implementation, damit der zufrieden ist.
Damit sind dann alle glücklich?

Du hast mich missverstanden. Ich meinte nicht deine Basisklasse sondern die abgeleiteten Klassen: du kannst niemandem vorschreiben einen Destruktor zu implementieren.

- ich deklariere Destruktor als rein virtuell mit "=0"
- ich definiere den Destruktor als leer "{}"

So hatte ich es schon vorher, nur wußte ich nicht, ob das so korrekt ist.

...
- ich deklariere Destruktor als rein virtuell mit "=0"
- ich definiere den Destruktor als leer "{}"
...

Hmmm, ich hätte auch immer gedacht, dass das eigentlich nicht geht; aber vermutlich habe ich die Bedeutung von "= 0" mißverstanden.

Ich dachte immer, das hieße: "Gibt's keine Definition von."
Dabei heißt es anscheinend: "Eine abgeleitete Klasse muß das 'overriden'. "

Hmmmm, muß ich nochmal drüber grübeln.

Gruß,

Simon2.

#include <iostream>

using std::cout;
using std::endl;

class foo1
{
public:
	virtual ~foo1() { cout << "foo1 destruktor" << endl; }
};

class foo2
{
public:
	~foo2() { cout << "foo2 destruktor" << endl; }
};

class bar1 : public foo1
{
public:
	~bar1() { cout << "bar1 destruktor" << endl; }
};

class bar2 : public foo2
{
public:
	~bar2() { cout << "bar2 destruktor" << endl; }
};

int main()
{
	foo1 *f1 = new bar1();
	foo2 *f2 = new bar2();

    // da der destruktor von foo1 virtuell ist,
    // wird erst der destruktor von bar1
    // und dann der destruktor von foo1 aufgerufen
	delete f1;

	// der destruktor von foo2 ist nicht virtuell,
    // also wird der destruktor von bar2 nicht aufgerufen,
    // somdern nur der von foo2
	delete f2;

	std::cin.get();
}

hier noch eine kleine demonstration der sinnlosigkeit von = 0 beim destruktor:

#include <iostream>

class sinnlos
{
public:
    virtual ~sinnlos() = 0;
};
sinnlos::~sinnlos() {}

class pustekuchen : public sinnlos
{
public:
    pustekuchen() { std::cout << "pustekuchen" << std::endl; }
    //um den destruktor braucht man sich, trotz = 0, nicht selbst zu kümmern
};

int main()
{
    pustekuchen p;
    std::cin.get();
}

Hmmm, ich hätte auch immer gedacht, dass das eigentlich nicht geht; aber vermutlich habe ich die Bedeutung von "= 0" mißverstanden.
Ich dachte immer, das hieße: "Gibt's keine Definition von."

Ich empfehle bezüglich dieser Problematik "More exceptional C++" von Herb Sutter
"Item27: (Im)pure virtual Functions"

...
Ich empfehle bezüglich dieser Problematik "More exceptional C++" von Herb Sutter
"Item27: (Im)pure virtual Functions"

Das ist gerade das einzige aus der Reihe, das ich noch nicht habe ...

Gruß,

Simon2.

das = 0 beim destruktor hat keine auswirkung auf das arbeiten mit der klasse; man kann eine eigene definition bei abgeleiteten klassen ebenso weglassen, als würde = 0 nicht verwendet. es reicht aus virtual zu benutzen

ich erlaube mir anzumerken, daß der abstakte destruktor die klasse abstrakt macht. versuch doch mal ein sinnlos-objekt anzulegen.

1.) In der abstrakten Basisklasse gibts keinen Destruktor (Was soll der tun?)
2.) Wenn jemand einen Destruktor braucht, dann muß er virtuell sein.

Ich habe nochmal das dicke Buch vom Herrn Stroustrup gewälzt. Da ist ein Beispiel für eine abstrakte Klasse. Die hat im Header einen leeren virtuellen Destruktor:

virtual ~lval_box() {}

Das scheint also durchaus die korrekte Vorgehensweise zu sein.

ich erlaube mir anzumerken, daß der abstakte destruktor die klasse abstrakt macht. versuch doch mal ein sinnlos-objekt anzulegen.

das ist natürlich richtig; ich habe mich falsch ausgedrückt. für stimpleton macht es halt keinen unterschied, da er ja sowieso abstrakte methoden in der basisklasse hat.

http://www.gotw.ca/gotw/031.htm

Das muß ich jetzt selber erstmal lesen...

das ist natürlich richtig; ich habe mich falsch ausgedrückt. für stimpleton macht es halt keinen unterschied, da er ja sowieso abstrakte methoden in der basisklasse hat.

ok. aber auch daran zweifle ich. kann mir irgendwie nicht vorstellen, daß man einen pur virtuellen destruktor in der unterklasse nicht redefinieren muss.

kann mir irgendwie nicht vorstellen, daß man einen pur virtuellen destruktor in der unterklasse nicht redefinieren muss.

der default-destruktor reicht offensichtlich aus. der basisklassen-destruktor ist ja in wirklichkeit definiert, so dass abgeleitete klassen ihn aufrufen können, und das "pur virtuell" ist in dem fall nur eine fassade um zu erzwingen, dass die basisklasse abstrakt ist. sehe ich persönlich auch als eine sehr merkwürdige design-technik an, weil man als client (ableiter) nicht sofort weiß, was denn nun konkretisiert werden soll. Da kann man ja konkretisieren, indem man einfach schreibt:

class konkret : public abstrakt {};

das kann doch nicht der sinn von abstrakten klassen sein, oder?

Da kann man ja konkretisieren, indem man einfach schreibt:

class konkret : public abstrakt {};

das kann doch nicht der sinn von abstrakten klassen sein, oder?

unwahrscheinlich.
so, wie man auch nicht schreibt

int main(){42;}

aber korrekt kannst doch sein.

...kann mir irgendwie nicht vorstellen, daß man einen pur virtuellen destruktor in der unterklasse nicht redefinieren muss.

(nur aus Test: )
Aber das Ergbnis ist dasselbe, ob nun mit "=0" oder ohne: Compiler hat kein Problem und Linker meckert fehlende Funktion an.

So gesehen wäre das "=0" tatsächlich überflüssig.

Gruß,

Simon2.