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
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
unique_ptr ist zu nutzen, wenn _nur_einer_ gleichzeitig ein Objekt verwenden darf, ungeachtet davon, wer sich ums Aufräumen kümmert.
shared_ptr/weak_ptr ist dann zu nutzen, wenn mehrere gleichzeitig ein Objekt verwenden dürfen, aber jeder dieses Objekt zu jeder Zeit benutzen darf.
unique_ptr ist zu nutzen, wenn _nur_einer_ gleichzeitig ein Objekt verwenden darf, ungeachtet davon, wer sich ums Aufräumen kümmert.
shared_ptr/weak_ptr ist dann zu nutzen, wenn mehrere gleichzeitig ein Objekt verwenden dürfen, aber jeder dieses Objekt zu jeder Zeit benutzen darf.[/align]
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (04.12.2014, 18:48)
Der Anwendungs-Fall ist folgender:
owned_ptr/borrowed_ptr ist dann zu verwenden, wenn ein Objekt (z.B. ein Manager) explizit Objekte besitzt, die von anderen benutzt werden dürfen, deren Verwendung allerdings über die Lebenszeit des Besitzers hinweg keinen Sinn ergibt. Das kann z.B. ein OpenAL-Buffer sein, der nur so lange zu verwenden ist, wie der OpenAL-Kontext existiert. Generell bei _allen_ Objekten, zu deren Dokumentation irgendwas wie "Don't use unless this/that..." oder "Don't delete, because..." steht.
Der Anwendungs-Fall ist folgender:
owned_ptr/borrowed_ptr ist dann zu verwenden, wenn ein Objekt (z.B. ein Manager) explizit Objekte besitzt, die von anderen benutzt werden dürfen, deren Verwendung allerdings über die Lebenszeit des Besitzers hinweg keinen Sinn ergibt. Das kann z.B. ein OpenAL-Buffer sein, der nur so lange zu verwenden ist, wie der OpenAL-Kontext existiert. Generell bei _allen_ Objekten, zu deren Dokumentation irgendwas wie "Don't use unless this/that..." oder "Don't delete, because..." steht.
unique_ptr ist zu nutzen, wenn _nur_einer_ gleichzeitig ein Objekt verwenden darf, ungeachtet davon, wer sich ums Aufräumen kümmert.
shared_ptr/weak_ptr ist dann zu nutzen, wenn mehrere gleichzeitig ein Objekt verwenden dürfen, aber jeder dieses Objekt zu jeder Zeit benutzen darf.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (04.12.2014, 18:59)
Quellcode |
|
1 2 3 |
shared_ptr & weak_ptr: 3624ms sole_ptr & dynamic_ptr: 1846ms unique_ptr & raw pointer: 928ms |
@dot: Die "Designfehler"-Keule liegt immer griffbereit Aber wie gesagt: Das Dungeon besitzt das Objekt und die KIs kennen/verwenden es. Ich sehe an diesem Design beim besten Willen keinen Fehler
Und shared ownership schließe ich mach wie vor (und in Anbetracht der Testergebnisse auch weiterhin) als Lösung aus.
Zitat von »Databyte«
Ich denke aber weak_ptr wird in deinem Design auf keinen Fall benötigt.
Werbeanzeige