spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zuerst: Was ist C/C++? C++ und C sind ein sehr ganzes Stück verschieden! Malloc (oder auch new) in C++ zu benutzen oder überhaupt C in C++ programmieren zu wollen grenzt an Wahnsinn.

Malloc richtet sich beim Alignment nach dem des größten eingebauten Datentyps, da ja schließlich sämtliche komplexen Typen aus diesen bestehen. Für die Angabe einer exakten Ausrichtung gibt es std::aligned_storage in C++. Was hat das mit einem GC zu tun?

Ganz ehrlich, eine der großen Stärken von C++11 und folgenden ist, dass Memory-Management sicher, einfach und vorhersagbar ist. Memory-Management ist genauso sicher und einfach geworden wie in GC-basierten Sprachen, hat aber einen gewaltigen Vorteil. Ich wüsste nicht, wieso ich diesen Vorteil durch einen GC vernichten wollen würde.

Jaja, hübsch kopiert und so, leider ziemlich veraltet. Sagen wir einfach: wenn Du GC willst, nimm kein C++.

Alignment ist davon ja unabhängig. Und da müssten die selben Regeln gelten wie für alle Typen in C++. Techel hat das bereits beantwortet.

Zitat von »JungleProgger«

It makes for cleaner code, there's no need to free something, the gc does this

Smart-Pointer in C++ ebenfalls. Der Vorteil liegt hier bei Smart-Pointern, denn man weiß sogar ganz genau wann es freigegeben wird.

Zitat von »JungleProgger«

No overhead of destructor calls and recursive freeing

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.

Zitat von »JungleProgger«

No need to deal with ownership issues

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.

Zitat von »JungleProgger«

No heap fragmentation (Boehm doesn't do this, but we're looking into alternative gc's that can)

Ja, das kann managed memory prima, allerdings kann das kein GC in C++, weil es rohe/unmanaged Pointer gibt.

Zitat von »JungleProgger«

Never access an already freed object

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)

Zitat von »JungleProgger«

A concurrent copying gc can actually improve allocation time.

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".

C++ mit einem GC zu benutzen, ist meiner Meinung nach Schwachsinn. Zwar gibt es durchaus Fälle, bei denen ein anderer als der Standardallokator benutzt werden sollte, aber ein GC hat meiner Meinung nach den eigentlichen Sinn verfehlt, dass ein Programmierer sich *nicht* um die Verwaltung von Objektspeicher kümmern muss. Stattdessen tut man tatsächlich das Gleiche wie in C auch, nämlich seine Ressourcen mit close() oder dispose() manuell oder halbautomatisch mit using oder try-with-resources in Java oder C# freizugeben. Das kann C++ eindeutig besser.

Mit Rekursion ist der (durchaus valide) Umstand gemeint, dass Member durch das Parentobjekt zerstört werden. Sieh dir beispielsweise eine naive Implementation einer verketteten Liste an. Jedes Element besitzt das Folgende durch einen std::unique_ptr. Folglich werden alle Elemente bei Zerstörung der Liste rekursiv gelöscht, was bei großen Listen einen Stapelüberlauf aufgrund zu großer Rekursionstiefe zur Folge hat.

Zitat von »JungleProgger«

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.

Hat du dir C++ 11 denn mal angesehen? Ich kann mich nicht dran erinnern wann ich das letzte mal delete genutzt habe und selbst irgendetwas aufräumen muss ich auch nichts. Dafür gibt es ja im Notfall die Smartpointer. Und wenn ich Rekursive oder Verschachtelte Typen habe werden die bei mir ganz normal und ohne Mehrarbeit von meiner Seite aufgeräumt.

Zitat von »JungleProgger«

Denke es geht, soweit ich weiß funktionieren nämlich diese Embeded-GC's anders als totalle managed-GC's wie in Java/C#

Da gibt es verschiedene Ansätze. Ein Ansatz ist jeden Wert im Speicher als Adresse anzusehen. Die Speicherzellen deren Adresse nicht als Wert im Speicher vorkommen können dann gelöscht werden. Das löscht unter Umständen viele viele Speicherstellen nicht. Kann gut sein dass es da mittlerweile neue, bessere Ansätze gibt.

Zitat von »JungleProgger«

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(..)

Aus welchem Grund soll GC_Malloc(...) schneller sein als ein einfaches new, selbst wenn das in make_unique oder whatever verpackt ist? Das kann ich mir so nicht vorstellen. Wenn du da mehr Infos zu hast, gerne her damit.

Nuja, zumindest new ist in GC-Sprachen tatsächlich schneller. Wenn Du aus einem Wegwerf-Heap schöpfen kannst, ist eine Allokation nur noch ein atomic_int.fetch_and_add(). Und das Aufräumen hinterher *kann* auch schneller sein, je nach Implementation. C++ hat seinen Performance-Vorteil primär daher, dass a) das Erzeugen und Aufräumen deterministisch passiert, also Du als Programmierer darüber bestimmen kannst. Und das willst Du, wenn's kritisch wird. Und wenn's nicht kritisch wird, nimmst Du was Anderes als C++. Außerdem kann b) C++ vieles auf dem Stack oder lokal allokieren, oder per Custom Allocator massive Geschwindigkeitsvorteile aus Kontextwissen ziehen. Auch das ist - wie gesagt - sehr wichtig, wenn's kritisch wird. Und wenn's nicht kritisch wird, nimmst Du kein C++.

Daher ist auch die Idee, C++ mit einer GC zu benutzen, nur übersichtlich clever. Leute, die aus der Java-Welt kommend alles mit new allokieren, produzieren in C++ schlimmeren Code als in Java. Zum Einen leakt das dann doch gern mal hier und da, weil das idiomatische C++ nunmal heutzutage quasi kein direktes new mehr braucht. Zum Anderen ist solcher Code langsamer als in Java, weil Allokationen in C++ nunmal teurer sind als in Java. In Java fehlen Dir dagegen die Mittel, sie ganz zu vermeiden.