Kann sich ein Objekt selbst zerstören?
-
Und die müsste dann statisch sein, damit man sie ohne Objekt aufrufen kann?!?!
-
uekue_ schrieb:
Und die müsste dann statisch sein, damit man sie ohne Objekt aufrufen kann?!?!
Genau.
-
Kann so eine Funktion dann über den new Operator das Objekt erzeugen oder muss man dann selbst den Speicher allokieren und den Konstruktor aufrufen?
also würde so eine Funktion reichen?//... static MyClass::Create() { return new MyClass(); } //...
-
//... static MyClass* MyClass::Create() { return new MyClass(); } //...
Und schlau ist es sicher, Smart-Ptr zu benutzen, dann muss sich der Nutzer der Methode nicht um die Freigabe kümmern.
-
Sicher, den Rückgabetypen hab ich wiedermal vergessen, wie so oft bei den Klassenmethoden... Irgendwie ein Fehler den ich jedesmal mache bis sich der Compiler beschwert...
Aber jetzt nochmal für die Dummen, was sind Smart-Ptr? Wenn sich der Benutzer nicht mehr um die Freigabe kümmern muss, ist das dann sowas wie ein Garbage-Collector bei Java??!?
-
Es ist ein Pointer, der das Objekt was er hält bei gewissen umständen selber löscht (Scope verlassen, keine Referenzen mehr auf das Objekt usw.)
Im Magazin ist da glaub ich ein Artikel zu, sonst könntest du auch mal bei boost.org vorbeischauen.
-
Ein Objekt kann sich selbst löschen, in der MFC wird das z.B. für die Notizen verwendet, die eingeblendet werden.
*schauer über den Rücken jag*
Das Dämliche an der Stelle ist nur, man weiß nie wann die Pointer auf so ein
Objekt ungültig wird, referenzieren/verweisen ist also ganz schlecht.
Man erzeugt sich damit für gewöhnlich schöne sporadisch auftretende Abstürze, wenn nicht garantiert werden kann das alle Pointer 100% auf Null gesetzt werden und das Objekt die Lösch-Funktion nicht selbst indirekt irgendwie aufruft (dann zerbröselt es die Anwendung auch).
Meiner Meinung nach erspart man sich am Besten diesen Ärger gleich und implementiert eine zentrale Instanz für die Verwaltung der Objekte. Das ist viel robuster.
-
MathiasTemp schrieb:
...
Sofern du dich jetzt mit deiner Aussage nicht ausschließlich auf die Microsoft-Bereiche beschränkst, ist sie IMHO völliger Unsinn.
Sofern man dafür sorgt das man konsequent mit Smartpointern arbeitet, ist immer der Zeitpunkt der Zerstörung garantiert, oder kann zumindest sinnvoll gegengeprüft werden (z.B. bei boost::scoped_ptr, oder der Kombination von boost::shared_ptr/boost::weak_ptr).
cu André
-
wer new sagt, sagt auch delete. 'nuff said.
-
Ob in einem Code "delete this" vorkommt oder nicht ist letztlich vollkommen egal. Man kann jeden Code der "delete this" verwendet so umschreiben dass es (zumindest "wörtlich") nichtmehr vorkommt, was aber IMO oft keinen Unterschied macht bzw. die Dinge sogar ... z.T. "undurchsichtiger" macht als notwendig.
Was hier diskutiert ist ist IMO weniger ob "delete this" OK ist, sondern ob gewisse Techniken/Patterns OK sind. Wie z.B. "intrusive reference counting" oder "detached objects" (mit "detached objects" meine ich hier Objekte die irgendwas tun und sich danach selbst zerstören, d.h. auf die man von Aussen keine Zeiger halten "sollte", und wenn doch eben irgendwoher wissen muss dass das Objekt sich zu dem Zeitpunkt wo man den Zeiger verwendet noch nicht selbst zerstört haben kann. Analog zu "detached threads" eben).
IMO gibt es durchaus Anwendungsfälle wo diese Techniken/Patterns gut und problemlos eingesetzt werden können. Natürlich können fast alle Techniken/Patterns zu Problemen führen wenn man sie "falsch" einsetzt, was diese aber nicht grundsätzlich schlecht oder gefährlich macht.
