spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wie das? Wie behandelst Du das Löschen denn dann, wenn die Handhabung der Objekte polymorph erfolgt, deren Zerstörung aber nicht?

Zitat von »David_pb«

Zitat von »stef«

Darunter fällt unter anderem auch das Verhalten beim Zerstören.

Aber nur unter anderem. Aber da du ohnehin virtuelle Methoden verwendest, könntest du den Destruktor vermutlich auch virtuell machen.

Zitat

Fehler 1 error C2248: "Base::~Base": Kein Zugriff auf protected Member, dessen Deklaration in der Base-Klasse erfolgte. d:\entwicklung\test_console_2008\test_console_2008\test.cpp 27 Test_Console_2008

Genau, das will man durch einen geschützten Destruktor haben.

Kann mir mal einer einen Anwendungsfall nennen. Ich verstehe den Sinn eines protected destructors offenbar noch nicht.

Der Sinn ist offenbar eine polymorphe Zerstörung zu unterbinden. Der Anwendungsfall ist mir aber auch nicht ganz klar, bzw. die Absicht dahinter, wieso man so etwas wollen würde oder wozu man es braucht.

In der Regel ist der konkrete Typ der Objekte bei deren Erzeugung sowieso bekannt. Wenn ich Objekte nicht polymoph erzeuge (z.B. über eine Factory), gibt es in normalerweise keinen Grund, sie polymoph zu zerstören:

Hmm, ich erzeuge meine so gut wie immer polymorph über eine Factory, weil ich sie aus Files de-serialisiere und nur im Editor erstelle und dann dort in Files serialisiere.

Zitat von »stef«

Kann mir mal einer einen Anwendungsfall nennen. Ich verstehe den Sinn eines protected destructors offenbar noch nicht.

Wenn du Objekte hast die sich per Design nicht polymorph verhalten sollen, aber die trotzdem spezialisiert werden dürfen (die STL Implementierung von VS ist voll mit Beispielen). In diesem Fall ist es praktisch den Destruktor der Basis zu schützen um defensiv zu bleiben und etwaige Fehler zu vermeiden.

Herb Sutter hat sogar folgende Guideline verfasst:

Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual.

Weitere Infos hier: Virtual Question #2: What About Base Class Destructors?

Letzten Endes ist es doch eine Frage welche Resourcen die Basis- und die Abgeleitete Klasse benutzen und wo diese wieder freigegeben werden müssen / sollen.
Wenn die Basisklasse z.B. einen protected Zeiger enthält und für diesen Speicher allokiert, dann kann man das frei geben im Destruktor der Basis- als auch der
abgeleiteten Klasse erledigen.
Für polymorphe Strukturen würde ich hier virtuelle Konstruktoren bevorzugen die jeweils hinter ihrer eigenen Klasse sauber machen.

Die Möglichkeit Objekte zu deleten, betrachte ich als Teil des Interface eines Typs und wird durch einen public virtual Destruktor im Interface ausgedrückt. Ich persönlich find sowas aber eigentlich eher unsauber, da es massive Einschränkungen an die Implementierungen des Interface impliziert.
Z.B. muss nun sichergestellt sein, dass sämtliche Instanzen aller jemals abgeleiteten Typen ausschließlich nur mit new erzeugt werden, Stackallokation, selbst placement new, ein eigener Allocator etc. ist plötzlich keine Option mehr, Typen mit Wertsemantik können das Interface überhaupt rein prinzipiell nichtmehr implementieren...

Wenn du mein Beispiel oben betrachtest, fällt auf, dass ImplementationA sogar einen funktionierenden Kopierkonstruktor hat. Wieso nicht, vielleicht macht es für Objekte vom Typ ImplementationA Sinn, sie zu kopieren!? Das Interface ist in der Regel völlig unabhängig von solchen Dingen, denn es ist ja gerade der Sinn von Polymorphie, Objekte unabhängig ihrer genauen Gestalt und Herkunft auf abstrakterer Ebene gleich zu behandeln...

Zitat von »dot«

Die Möglichkeit Objekte zu deleten, betrachte ich als Teil des Interface eines Typs und wird durch einen public virtual Destruktor im Interface ausgedrückt. Ich persönlich find sowas aber eigentlich eher unsauber, da es massive Einschränkungen an die Implementierungen des Interface impliziert.
Z.B. muss nun sichergestellt sein, dass sämtliche Instanzen aller jemals abgeleiteter Typen ausschließlich nur mit new erzeugt werden, Stackallokation, selbst placement new, ein eigener Allocator etc. ist plötzlich keine Option mehr, Typen mit Wertsemantik können das Interface überhaupt rein prinzipiell nichtmehr implementieren...

Wenn du mein Beispiel oben betrachtest, fällt auf, dass ImplementationA sogar einen funktionierenden Kopierkonstruktor hat. Und das macht ja nichts, vielleicht macht es für Objekte vom Typ ImplementationA Sinn, sie zu kopieren. Das Interface ist in der Regel völlig unabhängig von solchen Dingen...

Ich verstehe kein Wort !
Kannst du das auch in verständlichem Deutsch beschreiben.

Zitat von »dot«

Z.B. muss nun sichergestellt sein, dass sämtliche Instanzen aller jemals abgeleiteten Typen ausschließlich nur mit new erzeugt werden, Stackallokation (...) ist plötzlich keine Option mehr

OK, also scheinbar sind meine C++ Tage doch eindeutig zu lange her. Wieso ist das keine Option mehr, nur weil das Interface einen virtuellen Destruktor vorschreibt?