spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Sorry. Is aber eigentlich auch nicht wichtig von wem.

Zitat von »BlueCobold«

Zitat von »dot«

Es geht nicht darum, dass du das Objekt über den Basisklassenzeiger löschen kannst. Natürlich geht das. Der Punkt ist: Woher weiß der Verwender deines Interface, wie genau das Objekt über den Basisklassenzeiger zu löschen ist, wenn er das Objekt nicht selbst erzeugt hat.

Das sollte ihm entweder egal sein dürfen oder er sollte nicht in der Lage sein das Objekt zu zerstören - logisch, denn wenn ich nicht weiß wie, dann sollte ich es nicht dürfen, da ich es sonst eben falsch mache. Sagt mir leider noch immer nicht, wieso ein Interface keinen public virtual Destruktor vorgeben sollte.

Nun, wenn du einen public virtual Destruktor anbietest, dann ist der Benutzer deines Interface aber eben genau in der Lage, das Objekt zu deleten...

Zitat von »BlueCobold«

Dennoch ist in OOP nunmal generell ein Konstruktor und Destruktor (explizit oder implizit) erforderlich, da ein Objekt erzeugt und vernichtet werden *muss*.

Richtig, ein Objekt. Ein Interface ist aber eben ein Interface und kein Objekt.

Zitat von »BlueCobold«

Eine LED wird eigentlich nicht durch eine LED erzeugt und sie weiß nicht, wie sie erzeugt oder entsorgt wird. In OOP lässt sich dies aber nicht korrekt darstellen, nur über Konstruktor und Destruktor.

Eine LED wird natürlich nicht durch eine LED erzeugt. Die Erzeugung und Entsorgung sind aber spezifische Operationen, die zum Typ LED gehören. Konstruktor und Destruktor werden ja in der Regel auch nicht von einer Instanz vom Typ LED aufgerufen, sie erzeugen lediglich eine Instanz vom Typ LED bzw. entsorgen sie. Imo ist da alles in Ordnung...

Zugegeben, ich hab selber (in der Regel mangels einer besseren Idee) ab und zu tatsächlich auch Basisklassen mit virtuellen Destruktoren. Dennoch find ich in den meisten Fällen, dass das unschön ist und nicht Teil eines abstrakten Interface sein sollte und suche nach einer besseren Lösung...

Ich bin gern offen dafür, auch wenn ich diese momentan nicht benötige, da ich mich nur in C# und Java aufhalte und das Problem da gar nicht existent ist.

Zitat von »dot«

Zugegeben, ich hab selber (in der Regel mangels einer besseren Idee) ab und zu tatsächlich auch Basisklassen mit virtuellen Destruktoren. Dennoch find ich in den meisten Fällen, dass das unschön ist und nicht Teil eines abstrakten Interface sein sollte und suche nach einer besseren Lösung...

Wo genau liegt das Problem? Darin, nicht delete aufzurufen? Dann hilft eine virtuelle kill()-Methode, die intern den eigenen Destruktor aufruft und das eigenen Object über den richtigen Allocator selbst entsorgt. Hierzu muss allerdings die Most-Derived-Class sicherstellen, dass ihr Speicher immer auf genau eine Art alloziiert wird. Das Grundproblem liegt wohl genau darin, dass ein Objekt in der Regel nicht sicher weiß, wo es angelegt wurde. Eine sichere Freigabe erfordert also entweder rigorose Einschränkung der Speicherallokation, oder Zusatzinformation über den Speicherort.

Kill geht aber nicht bei einer Stack-Instanz. Also geht schon, danach könnte man es aber trotzdem noch verwenden, bei manchen Klassen sogar fehlerfrei. Das fände ich sehr unschön.

Natürlich, COM löst es ja z.B. über Release(), was ja deiner kill() Methode entspricht. Damit ist das dann zumindest explizit Teil des Interface, aber eben auch nicht unproblematisch, wie du schon gesagt hast.

Die imo beste Lösung ist, wenn derjenige, der das Objekt erzeugt, sich auch um dessen Zerstörung kümmert. Das ist einfach, sauber, natürlich...

Zitat von »BlueCobold«

Kill geht aber nicht bei einer Stack-Instanz. Also geht schon, danach könnte man es aber trotzdem noch verwenden, bei manchen Klassen sogar fehlerfrei. Das fände ich sehr unschön.

Deshalb schreibe ich ja, du musst in diesem Fall den Speicherort bereits bei der Klassendefinition rigoros einschränken. Das heißt konkret: Entweder gar keinen öffentlichen Zugang zur Implementierung (siehe COM) oder keinen öffentlichen Zugang zu den Konstruktoren (protected + statische Methode zur Objekterzeugung mit einem festgelegten Allocator). Dann kannst du auch keine Instanzen auf dem Stack mehr anlegen. Nicht mal mit Placement New.

Zitat von »dot«

Die imo beste Lösung ist, wenn derjenige, der das Objekt erzeugt, sich auch um dessen Zerstörung kümmert. Das ist einfach, sauber, natürlich...

Jep, sehe ich genauso.

Als "natürlich" würde ich es nicht bezeichnen. Weder in der Natur, noch in der Industrie zerstört der Erschaffer sein "Werk".