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
Und doch tun es so viele. Und so wird dabei zum Beispiel argumentiert: http://embedded-computing.com/guest-blog…t-iot-gateways/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...
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.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...
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Chromanoid« (20.05.2016, 11:04)
Wie verwaltet man denn zum Beispiel den Speicher eines Graphen in C++?
Ich kenne dieses Vorgehen so aus der Praxis nicht.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.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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.Graphen erstrecken sich ja dann oft über verschiedene Teile der Anwendung, ohne dass man es überhaupt richtig weiß
Wenn du tatsächlich zyklische Ownership in deinem Use-Case hast [...]
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?
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (20.05.2016, 12:02)
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.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.
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: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.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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.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.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Ich weiß nicht, über welche Praxis du da redest. Meine Erfahrung sieht da anders aus.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.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »BlueCobold« (20.05.2016, 12:22)
Alter Hase
Beruf: Softwareentwickler (aktuell Web/Node); Freiberuflicher Google Proxy
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.
Zitat
Doch; und genau das ist ja das Problem. Ein GC verhindert keine Leaks im Allgemeinen. Das einzige, das ein GC vermeidet, ist das Leaken von Heapobjekten (wobei man selbst darüber diskutieren kann). 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...
Da muss ich dir aber widersprechen. Warum sind denn die robustesten großen Anwendungen meist GC-managed?
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.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (20.05.2016, 13:00)
Werbeanzeige