J
camper schrieb:
nö, das problem hast du nur mit deinem nuke_ptr, nicht mit auto_ptr:
- wenn ein auto_ptr kopiert wird, ist das original in jedem falle leer
- wenn ein nuke_ptr kopiert wird, ist das original vielleicht noch verwendbar. es gibt aber keinerlei möglichkeit festzustellen, ob ein nuke_ptr, der kopiert wurde, noch verwendbar ist (sofern man eben nur das original hat). das bedeutet keinerlei fortschritt gegenüber auto_ptr, im gegenteil. insbesondere ist dein nuke_ptr eben nicht zur parameterübergabe geeignet (ausser in fällen, in denen man auch auto_ptr verwenden könnte). als funktionsergebnis bietet nuke_ptr ebenfalls keinerlei vorteile gegenüber auto_ptr.
Naja, bei auto_ptr bekomme ich halt einen Zugriff auf NULL anstatt auf eine unbestimmte adresse. Was ist daran besser? Zugegeben, bei einem auto_ptr kann ich vor dem zugriff überprüfen, ob das objekt nach vorhanden ist, aber an dem crahs der applikation ändert das nichts, stimmts?
wieso sollte das plötzlich gehen. *x wird immer noch in der funktion uebernahmekontrolle gelöscht; alles was danach passiert ist undefiniert.
Autsch. Mist. Sorry, ich habe mich nicht richtig ausgedrückt. Die Funktion (eigentlich die methode) uebernehmekontrolle() löscht das objekt nicht sofort. Es hängt das objekt in eine Verwaltungshirarchie ein, in der es später automatisch gelöscht wird.
Schau dir die Codeschnipsel unter der prämisse nochmal an, dann gibt es Sinn
boost.smart_ptr ist wahrscheinlich das richtige für dich.
Schau ich mir mal an.
[code]das problem ist ja nicht der smart pointer an sich, sondern die zu grunde liegende frage, wer wann welches objekt besitzt. die antwort auf diese frage bestimmt dann die wahl des smart pointers, der diese form des besitzes modelliert.[/quote]
Stimmt. Solange man nicht managed code schreibt, ist das sicher richtig. Wenn ich mir aber sowieso ständig Gedanken machen muss, wann, wie und wo das jeweils referenzierte objekt gelöscht werden soll, dann kann ich auch gleich so ein primitives Ding wie nuke_ptr nehmen. Sicher, ich kann dabei Fehler machen. das kann ich aber auch, wenn ich viele verschiedene Smart-Pointer benutze... wenn ich den falschen Pointer wähle, schmiert meine Applikation genau so schnell ab, wie bei einer falschen Benutzung von nuke_ptr. Außerdem kann man, in Verbindung mit einem entsprechenden Framework, das eben selbst keine Smart-Pointer verwendet, mit jedem Smart-Pointer, egal wie komplex oder primitiv, seine Software ganz schnell verwanzen.
Mir scheint, mit Smart-pointern wird man niemals sicherheit erreichen.