spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Dass man mit GC-Sprachen auch unangenehmen Situationen begegnet ist mir klar und das braucht ihr mir wirklich nicht erklären. Aus meiner Sicht verringert sich i.d.R. aber die Problemfläche für den gemeinen Programmierer ungemein.

Zitat von »dot«

Wir haben also auf der einen Hand eine einzige Art von Resource – nämlich Heapobjekte (≠ Speicher!) – auf der anderen Hand sämtliche anderen Arten von Resource. Der GC managed dir eine, der lächerliche Preis, den du dafür bezahlen musst, ist, dass korrektes Management aller anderen Arten von Resource praktisch unmöglich wird. Ein Geschäft, auf das sich niemand, der Recht bei Sinnen ist, einlassen sollte...

Und doch tun es so viele. Und so wird dabei zum Beispiel argumentiert: http://embedded-computing.com/guest-blog…t-iot-gateways/

Zitat von »dot«

Es ist schwer bis unmöglich, zyklische Besitzverhältnisse abzubilden und das ist auch gut so; das ist kein Nachteil, sondern gerade eben ein massiver Vorteil, weil der Compiler dir schon gar nicht erst erlaubt, diesen Fehler zu begehen, insbesondere nicht unabsichtlich. Zyklische Graphen an sich sind dagegen kein Problem...

Wie verwaltet man denn zum Beispiel den Speicher eines Graphen in C++? Ich bin da echt eingerostet. Muss man da nicht immer eine eigene Zyklus-Erkennung einbauen? Solche Graphen erstrecken sich ja dann oft über verschiedene Teile der Anwendung, ohne dass man es überhaupt richtig weiß. Dass man sowas ohne große Probleme in GC-Sprachen handlen kann, ist neben dynamischer Verlinkung mMn auch der Grund, warum man bei Nicht-GC-Sprachen nicht so ein sich rasant entwickelndes Open-Source-Öko-System hat - so zumindest mein Eindruck.

Zitat von »Chromanoid«

Wie verwaltet man denn zum Beispiel den Speicher eines Graphen in C++?

Das würde ich per Adjazenzmatrix oder Adjazenzlisten machen. Zumindest in den meisten Fällen. Aber nicht nur in C++ sondern auch in GC Sprachen. Das worauf du hinaus willst könnte man aber doch lösen indem eine Graphenklasse alle Knoten besitzt und die Knoten selbst kennen dann nur ihre Nachbarn, besitzen diese aber eben nicht. Abbilden könnte man das dann zum Beispiel durch raw-Pointer. Ich mache es zumindest so dass ich Besitz bei Zeigern durch unique_ptr festlege und raw-Pointer dann bei kennt-Beziehungen einsetze.

Zitat von »Chromanoid«

Zitat von »BlueCobold«

Das Ergebnis sind OutOfMemory-Probleme. Solches null-Setzen ist aber an sich auch kein schöner Stil. Nur leider in der Praxis unvermeidbar. Genauso, wie ein GC.collect/flush eben auch in gewissen Situationen unbedingt notwendig ist, so grauenvoll das auch weh tut solchen Code zu sehen oder selbst schreiben zu müssen.

Ich kenne dieses Vorgehen so aus der Praxis nicht.

Die Probleme gibt es aber. Meistens läuft es sogar darauf hinaus, dass man effektiv versucht den GC zu vermeiden. Und dass der Code dann in einer GC basierten Sprache unleserlich wird ist wohl klar.
Minecraft hat z.B. hauptsächlich wegen dem GC massive Performanceprobleme. Und dabei muss man beachten, dass dort der Rendercode schon in C++ ausgelagert ist und man bei dem Spiel auch nicht gerade von guter Grafik reden kann.
(https://www.reddit.com/r/programming/com…ny_performance/)

Zitat von »Chromanoid«

Graphen erstrecken sich ja dann oft über verschiedene Teile der Anwendung, ohne dass man es überhaupt richtig weiß

Dafür gibt es das Prinzip der Ownership. Da kann man wie schon gesagt nicht "ausversehen" einen Zyklus bauen, der eine Freigabe verhindert. unique_ptr und raw ptr sind in C++ dafür ein ideales Mittel der Wahl. Da hast du quasi einen Baum (keinen Graphen!) aus Ownership und non-owned-Referenzen, die das ganze dann zu einem Graphen machen. Es ist nicht möglich da versehentlich einen Zyklus aus Objekt-Ownership zu basteln (wie bei dem Ring-Example schon gezeigt). Wenn du tatsächlich zyklische Ownership in deinem Use-Case hast (und die hat man eigentlich zu 99.99% nicht - ich hatte z.B. noch keinen einzigen Fall, wo das der Fall gewesen wäre), dann kannst du das noch immer über shared_ptr ähnlich lösen wie das ein GC tun würde. Da ist ein GC vermutlich auch eine echt schöne Sache. Aber für die 0.01% der Fälle (von denen ich wie gesagt noch keinen einzigen jemals in der Praxis hatte), möchte ich mir nicht all die Nachteile eines GCs an's Bein binden.

Zitat von »Schorsch«

Das würde ich per Adjazenzmatrix oder Adjazenzlisten machen. Zumindest in den meisten Fällen. Aber nicht nur in C++ sondern auch in GC Sprachen.

Ah, verstehe, stimmt da war was Aber wir halten fest, es ist eine besondere Verwaltung nötig, die jetzt nicht unbedingt auf der Hand liegt, wenn man noch nicht einmal weiß, dass man gerade einen Graphen implementiert.

Zitat von »Schorsch«

Das worauf du hinaus willst könnte man aber doch lösen indem eine Graphenklasse alle Knoten besitzt und die Knoten selbst kennen dann nur ihre Nachbarn, besitzen diese aber eben nicht. Abbilden könnte man das dann zum Beispiel durch raw-Pointer. Ich mache es zumindest so dass ich Besitz bei Zeigern durch unique_ptr festlege und raw-Pointer dann bei kennt-Beziehungen einsetze.

Naja, das worauf ich hinaus will, sind eher Sachen wie zig Referenzen, die irgendwie zu einem Zyklus führen, ohne dass man überhaupt einen Graphen entwickeln will. Jede Bibliothek, die man benutzt, muss gegen sowas abgesichert sein oder etwa nicht? In GC-Sprachen ist das sehr viel unwahrscheinlicher, dass es da zu Problemen kommt. Ich versuche mal ein Beispiel an den Haaren herbeizuziehen , vielleicht problematisiere ich hier auch, aber ich glaube das ist wirklich schnell mal ein Problem:

[ Service A (Bibliothek 1) -nutzt-> Service B (Bibliothek 2) ] Außerhalb der Organisation
[ Service B (Bibliothek 2) -verwaltet-> Objekt X (User Code) ] Aufgabenbereich Team 1
[ Objekt X (User Code) -nutzt-> Service A (Bibliothek 1) ] Aufgabenbereich Team 2

Der Zyklus entsteht hier durch die ungünstige Implementierung von Objekt X. Das ist natürlich nicht sauber entwickelt, aber der Zyklus ist erst mal nicht so einfach nachzuvollziehen, insbesondere wenn Interfaces verwendet werden, die den Zyklus im Code nicht deutlich machen.

Zitat von »Chromanoid«

Naja, das worauf ich hinaus will, sind eher Sachen wie zig Referenzen, die irgendwie zu einem Zyklus führen, ohne dass man überhaupt einen Graphen entwickeln will.

Das ist in Referenz-Sprachen ein echtes Problem. In C++ ist das z.B. überhaupt gar keins, denn bei sauberer C++ Verwendung, ist das technisch nicht möglich zu implementieren.

Interfaces oder nicht sind hier völlig irrelevant. Du darfst durchaus zyklische Datengraphen haben. Aber du solltest niemals einen Besitz-Zyklus haben. In sauberem C++ kannst Du so einen bei klarem Verstand nicht versehentlich bauen. In Java oder C# ist das natürlich überhaupt kein Problem und da ist der Fehler.

Zitat von »LetsGo«

Das man in sehr abstrusen Situationen einen Leak bekommt mag sein, aber das ist in 99,9% der Fälle nicht der Fall. Der GC managed Speicher in großen Anwendungen besser als die Summe der Entwickler.

Ich weiß nicht, über welche Praxis du da redest. Meine Erfahrung sieht da anders aus.
Der Vorteil bei "Crashes" in C# oder Java ist einfach der, dass man sie wesentlich einfacher catchen und behandeln kann als einen Zugriff auf ungültigen Speicher in C++. Das ist so, ja. Das ist zumeist auch die allseits beliebte NullPointer/NullReferenceException, weil jemand zu dumm war einen Optional Value vor Verwendung nicht auf Inhalt zu prüfen. Dafür brauche ich aber nur Managed Memory, ich benötige dafür nicht automatisch auch Garbage Collection. Wahlweise kann ich dafür auch eine Sprache verwenden, die solche Prüfungen unabdingbar macht. Wie eben z.B. Swift oder Rust. Außer man benutzt sie inkorrekt und äußerst dämlich, verhindert schon die Sprache / der Compiler einen Zugriff auf invaliden Speicher oder einen Nullpointer (ja, richtig gelesen, korrekt eingesetztes Swift macht einen Nullpointer-Zugriff unmöglich schon zur Compile-Zeit!). DAS ist z.B. eines der Oberhammer-Dinge, die an Swift richtig geil sind. Und Swift hat weder, noch braucht es, einen GC.

Zitat von »Helmut«

Und dabei muss man beachten, dass dort der Rendercode schon in C++ ausgelagert ist und man bei dem Spiel auch nicht gerade von guter Grafik reden kann.

Quelle? Es wäre mir neu, dass Minecraft das Rendering in C++ abwickelt. Ich rede hier nicht von der eigentlichen OpenGL Implementierung, bzw den lwjgl Libs, sondern von der Renderlogik. Der GC ist in Minecraft so eine Performancebremse, weil man irgendwann mal ziemlich viel vom Datenmodell refactored hat und dabei nicht an die Eigenheiten des GC gedacht hat.