spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

In vielen Fällen sind std::unique_ptr oder std::shared_ptr sogar besser als rohe Zeiger. Solltest dich evtl. mal über sie informieren.

Als kleinen Buchtipp, sofern du es nicht eh schon hast wäre von mir im Zusammenhang mit Speicherverwaltung auf Betriebssystem Ebene:

Moderne Betriebssysteme von Andrew S. Tannenbaum

Sollte man sich aber nur anschaffen wenn in diesem Bereich wirklich Interesse vorliegt.

Was für dich vlt auch sehr interessant sein könnte, ist Garbage Collection. Da geht es zwar hauptsächlich ums Freigeben von Speicher, aber je nachdem wie man sich das ganze ausdenkt, kann man sehr nette (und schnelle) allocatoren bauen.

Java verwendet (u.a) z.B Copy Collection. Das bedeutet, sie Erzeugen die Objekte genau so wie du das machst. Wenn der Speicher dann (fast) voll ist, kommt der Garbage Collector und identifiziert alle "toten" Objekte.
Dann kopiert er einfach alle lebenden Objekte an den Anfang des Speicherbereiches, und kann dann so wie bei deinem Stack-Allocator weiter machen... Dazu kommen noch Generationen etc.

Bei C++ wird dir das ganze natürlich eher weniger bringen, es sei denn du implementierst deine eigene VM.

Genau dafür gibt es in C++ Smart-Pointer - damit man kein Garbage-Collection bauen muss.

Zitat von »BlueCobold«

Genau dafür gibt es in C++ Smart-Pointer - damit man kein Garbage-Collection bauen muss.

Schon, aber falscher Umgang - z.B. durch Zyklen - und man hat ein Problem. Das passiert mit einem GC nicht so leicht. Aber hat halt alles Vor- und Nachteile, ich persönlich ziehe Ref Counting á la Smart Pointer auch vor.

Bei Zyklen haben auch Garbage-Collectoren gern mal ein Problem. Ich kenne auch kein gutes Design, wo Element X der Eigentümer von Y ist, Y der von Z und Z der von X. Da ist dann irgendwas anderes schief gelaufen.

Zitat von »BlueCobold«

Bei Zyklen haben auch Garbage-Collectoren gern mal ein Problem. Ich kenne auch kein gutes Design, wo Element X der Eigentümer von Y ist, Y der von Z und Z der von X. Da ist dann irgendwas anderes schief gelaufen.

Naja, gerade am Anfang ist selten gutes Design an der Tagesordnung. Da kann das dann schon mal passieren. Und IMO sollte jeder halbwegs guter GC mit Zyklen klar kommen, sofern er nicht auch per Ref Counting arbeitet.

GCs benutzen eher selten ref counting (jedenfalls wenn sie performant sein wollen, angelscript und lua verwenden z.b. ref counting ), weil es praktisch ein Mittelfinger für den Cache ist und dann noch zyklische referenzen als problem hat. Da wird lieber mit mark-and-sweap (+verbesserungen) und Generationen gearbeitet. Und bei diesen Techniken sind Zyklen kein problem.

PS: Obwohl... ich glaube ich hab mal irgendwo gelesen, dass php bis version 4 oder so keine zyklischen referenzen auflösen konnte... gut aber da ist das auch nicht so schlimm.

Zitat von »Databyte«

GCs benutzen eher selten ref counting (jedenfalls wenn sie performant sein wollen, angelscript und lua verwenden z.b. ref counting ), weil es praktisch ein Mittelfinger für den Cache ist und dann noch zyklische referenzen als problem hat. Da wird lieber mit mark-and-sweap (+verbesserungen) und Generationen gearbeitet. Und bei diesen Techniken sind Zyklen kein problem.

Objective-C arbeitet AFAIK nun auch mit ARC (Automatisches Ref Counting).

Zitat von »Databyte«

PS: Obwohl... ich glaube ich hab mal irgendwo gelesen, dass php bis version 4 oder so keine zyklischen referenzen auflösen konnte... gut aber da ist das auch nicht so schlimm.

Wenn du dazu nochmal etwas findest hätte ich gerne den Link.

Objective-C nutzt semi-automatisches Ref-Counting über Retain() und Release().