Abstrakte Destruktoren

stimpleton

Der Großteil des Buches ist auch im Netz zu finden...

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

Das muß ich jetzt selber erstmal lesen...

volkard

zerstörer schrieb:

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.

volkard schrieb:

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?

volkard

zerstörer schrieb:

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.

Simon2

volkard schrieb:

...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.

stimpleton

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

... da die Abstraktheit der Klasse durch andere abstrakte Funktionen garantiert ist.

Falls sonst keiner virtuell sein mag, dann nehmen wir den Destruktor und machen ihn abstrakt.

Herb Sutter: If the class should be abstract but it doesn't happen to have any other pure virtual functions, a common technique to make the destructor pure virtual:

Allgemein läßt sich somit sagen: C++ ist nicht ganz einfach und kann zu erheblicher Verwirrung führen.

finix

volkard schrieb:

zerstörer schrieb:

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.

Das erledigt zur Not der Compiler für dich.

volkard

finix schrieb:

volkard schrieb:

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

Das erledigt zur Not der Compiler für dich.

*mir an die stirn hau*

Simon2

stimpleton schrieb:

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

... da die Abstraktheit der Klasse durch andere abstrakte Funktionen garantiert ist.

Falls sonst keiner virtuell sein mag, dann nehmen wir den Destruktor und machen ihn abstrakt.....

Hatte ich auch gelesen (und verstanden) ... allerdings bin ich immer noch ein wneig enttäuscht/überrascht, dass der Standard offensichtlich doch kein "overriding erzwingt", sondern man mit einem einfachen Zweizeiler im eigenen Code sofort die "Abstraktheit übersteuern" kann

class Concrete : public Abstract {}; 
Abstract::~Abstract() {}

Hat man einmal für die Basisklasse (!!) eine Dummy-Implementierung hinzugefügt, kann man beliebig oft ableiten (horizontal wie vertikal) und niemandem fällt mehr auf, dass man die Schnittstelle nicht erfüllt hat.

Ich hätte z.B. erwartet, dass ein Compiler das Vorhandensein einer Implementierung ablehnt, wenn in der Klassendeklaration die Methode mit "=0" gekennzeichnet ist.

Aber nun gut; muß man eben noch mehr aufpassen.

Gruß,

Simon2.

finix

Simon2 schrieb:

allerdings bin ich immer noch ein wneig enttäuscht/überrascht, dass der Standard offensichtlich doch kein "overriding erzwingt",

Genau das erzwingt er. (Google: default destructor)

Simon2 schrieb:

sondern man mit einem einfachen Zweizeiler im eigenen Code sofort die "Abstraktheit übersteuern" kann
class Concrete : public Abstract {}; 
Abstract::~Abstract() {}

Dein Code ist mehr oder weniger falsch.

Simon2 schrieb:

Hat man einmal für die Basisklasse (!!) eine Dummy-Implementierung hinzugefügt, kann man beliebig oft ableiten (horizontal wie vertikal) und niemandem fällt mehr auf, dass man die Schnittstelle nicht erfüllt hat.

Deine Vermutung ist falsch, aber selbst wenn - was sollte der Compiler tun?

Simon2

finix schrieb:

...

class Concrete : public Abstract {}; 
Abstract::~Abstract() {}

Dein Code ist mehr oder weniger falsch.
...[/quote]

Kannst Du das etwas genauer spezifizieren ?
In diesem Thread habe ich gerade gelernt, dass das Implementieren einer "pure virtual function" durchaus erlaubt ist.

Was der Compiler tun kann ?
Nun, so, wie er überprüft, ob die Signatur einer Funktion stimmt, könnte er ein "=0" abchecken....

Gruß,

Simon2.

finix

Simon2 schrieb:

Kannst Du das etwas genauer spezifizieren ?
In diesem Thread habe ich gerade gelernt, dass das Implementieren einer "pure virtual function" durchaus erlaubt ist.

Jede Klasse muss einen Destruktor haben.
(->Wenn ~Abstract() nicht implementiert ist (vorzugsweise in Abstract.[c|h]pp) beschwert sich der Linker weil er's nicht findet, wenn du's nochmal implementierst beschwert er sich weil's doppelt ist)

Simon2 schrieb:

Was der Compiler tun kann ?
Nun, so, wie er überprüft, ob die Signatur einer Funktion stimmt, könnte er ein "=0" abchecken....

Wie sieht's bei folgendem Code aus, was soll der Compiler machen?

struct foo
{
  virtual void blob() = 0;
};
struct dummy_implemented : foo
{
  virtual void blob() { }
};

Simon2

finix schrieb:

...
Wie sieht's bei folgendem Code aus, was soll der Compiler machen?
struct foo
{
  virtual void blob() = 0;
};
struct dummy_implemented : foo
{
  virtual void blob() { }
};

Nun, was ein Compiler eben tut:

feststellen, dass foo::blob() pure virtual ist und korrekterweise keine Implementation vorliegt.
dummy_implemented::blob() entsprechend in die vtable von dummy_implemented aufnehmen

Dein Beispiel widerspricht ja gar nicht meinem Wunsch, dass der Compiler eine Implementation einer pure virtual function abweisen sollte....

Wenn ich das recht verstehe, ist der relevante Punkt, dass es eine Destruktor-Implementation geben muß, was natürlich bei anderen Funktionen anders ist (die können entweder ganz fehlen (inkl. Deklaration) oder "pure virtual" sein). Deswegen KANN er die Implementation einer "pure-vit-Dtors" gar nicht abweisen (weil der Linker sie letztlich braucht) ... bei anderen Funktionen könnte er es aber tun.....
Letztlich hat man nur die Wahl zwischen 2 Inkonsistenzen:

Entweder lässt man eine Implementation zu "reinen Funktionsinterfaces" zu
oder man behandelt Dtoren anders als andere Funktionen

Anscheinend hat man sich für Ersteres entschieden - ich persönlich hätte Zweiteres (z.B. in der Variante, dass Dtoren nicht pure virtual sein dürfen) etwas plausibler gefunden (welchen Sinn machen eigentlich abstrakte Basisklassen, die keine "echte" pure-virt-function haben ?).

Und letztlich bstimmt damit der Satz "eine abstrakte Klasse kann nicht instantiiert werden" nicht in seiner Absolutheit .... weil sie als Basisklasse einer abgeleiteten Klasse doch instantiiert wird - nur eben "automatisch" und niemals "manuell".

Gruß,

Simon2.

finix

Simon2 schrieb:

Wenn ich das recht verstehe, ist der relevante Punkt, dass es eine Destruktor-Implementation geben muß

Nein, nicht ganz: der springende Punkt an diesem Beispiel ist dass der Compiler automatisch einen Destructor einbaut falls du selber keinen deklarierst.
Dein Beispiel ein wenig abgeändert funktioniert daher nicht wie du befürchtest:

struct foo
{
  virtual void blob() = 0;
};

// ...

struct bar : foo { };
void foo::blob() { }

// ...

bar brawl; // error: bar is abstract

Simon2

finix schrieb:

Simon2 schrieb:

Wenn ich das recht verstehe, ist der relevante Punkt, dass es eine Destruktor-Implementation geben muß

Nein, nicht ganz: der springende Punkt an diesem Beispiel ist dass der Compiler automatisch einen Destructor einbaut falls du selber keinen deklarierst....

Also eben doch: Er baut einen, weil es einen geben muß

Ich wollte gar nicht ausdrücken, dass der Programmierer einen schreiben muß, sondern eben nur "es muß einen geben" .... und da unterscheidet sich eben der Dtor von blob() und Co. Der Compiler würde nämlich kein blob() selbst bauen.

Zum Code: Ich meinte, dass ich da ausprobiert habe, habe hier aber gerade keinen Compiler greifbar ....(auf dem Rechner meiner Frau ist eben keiner ).

Aber Dein Code stellt genau meine o.g. Alternativen dar:

Entweder compiliert er problemlos => man kann also doch "pure-virt-functions" implementieren
oder er weist es ab => der Compiler behandelt Dtoren (deren Implementation er ja offensichtlich nicht abweist) anders als andere virt-funcs.

Wie man es dreht: Ganz "schön" bekommt man es eben nicht hin.
(wobei ich es schöner fände, wenn er bereits das Auftreten von "foo::blob() {}" anmeckern würde......

Gruß,

Simon2.

THX 1138

Marc++us schrieb:

in seinem tollen Buch:
Wann immer eine Methode, ein Member, eine Methode eines Members oder eine Basisklasse etc.. abstrakt ist, sollte der Destruktor auch abstrakt sein.

Oder so ähnlich, habs jetzt nicht dabei.

finix

Simon2 schrieb:

Also eben doch: Er baut einen, weil es einen geben muß

Nein, du verstehst mich nicht richtig. Versuch mein voriges Beispiel zu kompilieren und du wirst, denke ich, sehen was ich meine.

Der Compiler baut den Destruktor in Concrete - den Destruktor in Abstract musst du implementieren, da du ihn deklariert hast.

finix

1310-Logik schrieb:

Marc++us schrieb:

in seinem tollen Buch:
Wann immer eine Methode, ein Member, eine Methode eines Members oder eine Basisklasse etc.. abstrakt ist, sollte der Destruktor auch abstrakt sein.

Oder so ähnlich, habs jetzt nicht dabei.

Ich kenne das Buch nicht, könnte aber wetten dass Marc++us, sinnvollerweise, "virtuell" anstatt "abstrakt" geschrieben hat.

THX 1138

finix schrieb:

1310-Logik schrieb:

Marc++us schrieb:

in seinem tollen Buch:
Wann immer eine Methode, ein Member, eine Methode eines Members oder eine Basisklasse etc.. abstrakt ist, sollte der Destruktor auch abstrakt sein.

Oder so ähnlich, habs jetzt nicht dabei.

Ich kenne das Buch nicht, könnte aber wetten dass Marc++us, sinnvollerweise, "virtuell" anstatt "abstrakt" geschrieben hat.

Kann sein, ich kann mir Merksätze nie merken

Simon2

finix schrieb:

Simon2 schrieb:

Also eben doch: Er baut einen, weil es einen geben muß

Nein, du verstehst mich nicht richtig. Versuch mein voriges Beispiel zu kompilieren und du wirst, denke ich, sehen was ich meine.

Der Compiler baut den Destruktor in Concrete - den Destruktor in Abstract musst du implementieren, da du ihn deklariert hast.

Hi,

also ich habe jetzt mal ein wenig getestet:

struct foo
{
  virtual ~foo() = 0;
  virtual void f() = 0;
};

struct bar : foo { };
foo::~foo() { }
void foo::f() {}

Ergebnis:

Ohne Instantiierung eines bar hat der Compiler keine Probleme
Mit Instantiierung stößt er sich an "der Virtualität von f" an der Stelle der Implementierung von foo::f().
Mit Einführung von bar::f() ist alles OK.
Ohne Implementation von ~foo() hat der Compiler keine Probleme, aber der Linker moniert den fehlenden Dtor.

Ergo => Der Compiler handhabt pure-virt-Dtors anders als "normale pure-virt-funcs" .... so, wie ich vermutet habe. Bei dem Einen duldet (ja sogar: fordert implizit) er etwas, was er beim Anderen verbietet.

Aber Du hast Recht mit: Dass der Compiler selbst einen foo-Dtor baut, stimmt nicht !
War zwar auch nicht so gemeint, aber in dem Zusammenhang wirklich mißverständlich von mir.
Einig sind wir uns aber wohl mit: Der Compiler erzeugt auf jeden Fall einen Aufruf des foo-Dtors automatisch, wenn man ein bar-Objekt instantiiert.

Gruß,

Simon2.