Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Evtl. hab ich dich jetzt falsch verstanden, aber das ist ja grad das geniale am shared_ptr. Wenn ein shared_ptr out-of-scope geht, dann wird die referenzierte Ressource nur dann freigegeben, falls es der letzte shared_ptr ist. In allen anderen Fällen, wird einfach den geteilten Reference Counter hinunter gezählt. Wenn also nun dein Programm "normal" beendet wird, dann werden alle shared_ptr gelöscht, d.h. alles Destruktoren der shared_ptr werden aufgerufen und somit wird der Reference Counter hinunter gezählt bis es nur noch einen gibt und der Destruktor dessen gibt dann die Ressource frei.Ich wollte eigentlich wissen, wie der Destruktor des shared_ptr sicherstellt, dass falls er die Ressource (bspw. dynamisch alloziierter Speicher) löschen soll, diese in JEDEM Fall freigegeben wird. Was macht er also, wenn ein Fehler (Exception) auftritt? Propbiert er es endlos erneut, oder kehrt er einfach zum Aufrufer zurück, und lässt die Ressource in einem ungültigen Zustand zurück? Wie stellt er seine Exception-Garantie sicher?
Warum sollte der Deallocator sowas tun? Es gibt für meine Allokatoren nur einen Fehler, der auftreten kann, wenn man deallokiert: Eine Assertion, wenn der Speicher nicht von genau diesem Allokator geholt wurde. Und da auch wirklich assert, denn das wäre nicht zu tolerieren.Zitat
(Beispiel: Custom Deallocator wirft eine Exception, da Datenbank-Verbindung nicht geschlossen werden konnte)
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
Stell dir einfach eine Funktion einer externen API db.Close() vor, die eben im Destruktor aufgerufen wird. Diese kann allerdings aus was für Gründen auch immer eine Exception werfen. In solchen Fällen "schlucke" ich die Exception wie gesagt einfach. Oder gibt es da eine bessere Variante?
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Werbeanzeige