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
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Techel« (04.05.2017, 23:21)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Smart-Pointer in C++ ebenfalls. Der Vorteil liegt hier bei Smart-Pointern, denn man weiß sogar ganz genau wann es freigegeben wird.It makes for cleaner code, there's no need to free something, the gc does this
Das ist schlicht falsch. Gelöscht werden muss sowieso, notfalls auch rekursiv und Destruktoren müssen trotzdem gerufen werden. Selbst in Java und C# gibt's das, nennt sich Finalizer. Braucht man nicht so oft und auch in C++ sind sie seit 11 fast absolet geworden - zumindest genauso selten wie Finalizer in managed Sprachen. Solange wie Datenstrukturen verschachtelt sind, muss auch 'rekursiv' gelöscht werden. Jede Rekursion lässt sich auch als Schleife ausdrücken und wenn es also nur um die Rekursion als Fakt geht, dann ist der Punkt unsinnig. Verschachtelte Datentypen müssen inklusive aller ihrer Kinder aufgeräumt werden. Ob das nun per Rekursion oder per Schleife erfolgt, ist völlig unerheblich.No overhead of destructor calls and recursive freeing
Anders ausgedrückt: Hirn abschalten beim Programmieren, zirkuläre Abhängigkeiten bauen und schon gibt der GC nie wieder etwas frei. Folgerichtig muss man sich darüber in sauberen Programmen basierend auf GC-Sprachen auch Gedanken machen. Also so wie's da steht im Grunde falsch.No need to deal with ownership issues
Ja, das kann managed memory prima, allerdings kann das kein GC in C++, weil es rohe/unmanaged Pointer gibt.No heap fragmentation (Boehm doesn't do this, but we're looking into alternative gc's that can)
Sowas ähnliches gibt's auch in GC-Sprachen. Nennt sich NullPointerException. (Ja, es gibt durchaus weak References in GC-Sprachen, jede hat da so ihr eigenes Konzept)Never access an already freed object
Für schnellere Allocations in C++ braucht man keinen GC und das hat mit einem GC auch nichts zu tun, denn "allocation" ist das Gegenteil, bzw. andere Ende von "Garbage".A concurrent copying gc can actually improve allocation time.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »BlueCobold« (05.05.2017, 14:23)
Das mit der Rekursion ist glaube ich so gemeint, dass man es nicht explicit im Code machen muss, der GC wird das über sein Tracing verfahren machen, also abgekoppelt von deinem Blickfeld und somit sauberer Code entsteht.
Denke es geht, soweit ich weiß funktionieren nämlich diese Embeded-GC's anders als totalle managed-GC's wie in Java/C#
Also, der Embeded-GC von Boehm, übernimmt sowohl die Allokation als auch das Finalisieren der Instanzen, nämlich über:
GC_Malloc(...), GC_Malloc_Atomic(...), GC_Free(..)
Werbeanzeige