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
Es ist eben i.d.R. kein Problem bei GC-Sprachen, weil das einfach der natürliche Programmierstil dieser Sprachen ist. Und von dem behaupte ich, dass er einfacher ist als der Programmierstil ohne GC. Nur weil man das technisch nicht mit C++ lösen kann, heißt das nicht, dass der Use Case nicht berechtigt ist.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.
Naja, sonst könnte man argumentieren, dass man den Zyklus mit statischer Code Analyse ja sehr leicht finden kann.Interfaces oder nicht sind hier völlig irrelevant.
Wenn man alles sauber und mit klarem Verstand machen würde, dann gäbe es ja gar keine Probleme, egal welche Sprache man verwendet.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.
Das sehe ich nicht so. In vielen Fällen ist die Anzahl der extern verwendeten Ressourcen irrelevant. Transaktionen und Datenbankzugriffe werden wegabstrahiert.Nochmal: Der GC managed nicht Speicher allgemein, der GC managed nur Heapobjekte und sonst nichts. Und genau das ist das Problem...
Bei so einer Einstellung ist man mit einer GC-Sprache deutlich besser dran. Mir geht es nicht so wie Lerdorf, aber ich hasse es mich um technische Details zu sorgen, die ich auch automatisch machen lassen kann. Ich will möglichst abstrakt arbeiten.Zitat
* I actually hate programming, but I love solving problems.
* There are people who actually like programming. I don’t understand why they like programming.
* I’m not a real programmer. I throw together things until it works then I move on. The real programmers will say “Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that.” I’ll just restart Apache every 10 requests.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Chromanoid« (20.05.2016, 13:31)
Das wird sich zeigen. Ich finde ARC eine gute Sache. Python nutzt das ja auch - zusammen mit Zyklus-Erkennung durch einen GC. Ich bin ja kein absoluter Fan von GC sondern dem Feature, dass ich mich nicht um Speicherverwaltung kümmern muss.Und Swift hat weder, noch braucht es, einen GC.
Ja, oder zum Beispiel den neuen Stern (?) am JVM Himmel Kotlin. Ganz interessanter Beitrag zu dem Thema von Lukas Eder (ein bekannter Java-Ökosystem-Blogger) mit einer weiteren interessanten neuen JVM-Sprache Ceylon: https://blog.jooq.org/2016/03/15/ceylon-…ot-nulls-right/Wahlweise kann ich dafür auch eine Sprache verwenden, die solche Prüfungen unabdingbar macht. Wie eben z.B. Swift oder Rust.
Community-Fossil
Vielleicht geht es ja um einen Konflikt, den Rasmus Lerdorf (Erfinder von PHP) mal beschrieben hat:
Bei so einer Einstellung ist man mit einer GC-Sprache deutlich besser dran. Mir geht es nicht so wie Lerdorf, aber ich hasse es mich um technische Details zu sorgen, die ich auch automatisch machen lassen kann. Ich will möglichst abstrakt arbeiten.Zitat
* I actually hate programming, but I love solving problems.
* There are people who actually like programming. I don’t understand why they like programming.
* I’m not a real programmer. I throw together things until it works then I move on. The real programmers will say “Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that.” I’ll just restart Apache every 10 requests.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Hier sind wir bei den Worten hinreichend und notwendig...Naja, sonst könnte man argumentieren, dass man den Zyklus mit statischer Code Analyse ja sehr leicht finden kann.
Nein. Eben nicht. Es ist in Java unmöglich festzustellen, ob und wann Du mit einem Objekt einen Daten-Zyklus baust und wann nicht. Das hast Du doch sogar schon selbst festgestellt beim Thema Interfaces. Da kann man noch so sehr bei klarem Verstand sein, man kann es gar nicht entscheiden.Wenn man alles sauber und mit klarem Verstand machen würde, dann gäbe es ja gar keine Probleme, egal welche Sprache man verwendet.
Muss man doch i.d.R. auch gar nicht, weil der GC das sehr gut lösen kann. Du misst hier die Qualität der Abhängigkeiten/Besitzstrukturen mit dem Maß eines C++-Entwicklers. Das ist bei GC-Sprachen aber das falsche Maß. Ich messe doch auch nicht C++-Strukturen mit dem Qualitätsmaß von Java-Entwicklern. Ich sage lediglich, dass ich häufig so entwickeln möchte, dass das Maß der GC-Sprachen besser passt und ich glaube, dass das sehr vielen so geht.Nein. Eben nicht. Es ist in Java unmöglich festzustellen, ob und wann Du mit einem Objekt einen Daten-Zyklus baust und wann nicht. Das hast Du doch sogar schon selbst festgestellt beim Thema Interfaces. Da kann man noch so sehr bei klarem Verstand sein, man kann es gar nicht entscheiden.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »BlueCobold« (20.05.2016, 14:13)
Genau an diesen Stellen muss man sich eben Gedanken machen ob eine GC-Sprache die richtige Wahl ist. Ich weiß nicht wie man i.d.R. mit Unity arbeitet, aber ich glaube so "wo man plötzlich anfängt wild Sachen auf null zu setzen und GC.collect zu rufen und solch grauenvolle Dinge" hoffentlich nicht.Was er aber auch nur bei Heap-Objekten kann und was bei Ressourcen ein echtes Problem wird. Ich denke da z.B. an Video- oder Audio- oder Textur-Daten. Genau solche Sachen sind in Spielen ein echtes Problem, wo man plötzlich anfängt wild Sachen auf null zu setzen und GC.collect zu rufen und solch grauenvolle Dinge... und das nur in der Hoffnung (und ohne Garantie!), dass es was hilft und man nicht out of memory geht.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Ich dachte wir argumentieren ganz allg. darüber. Und da ist meine Antwort natürlich "It depends" mit Tendenz zu "Meist ein Segen" und Deine scheinbar "Immer ein Fluch".Tja, ich eben nicht. Ich sehe bei einem GC eben spätestens seit C++11 keinen Vorteil mehr, sondern nur noch Nachteile. Auch in C++ muss ich mich nicht um Memory-Management kümmern und da gibt es keinen GC und auch keine Probleme mit Ressourcen-Freigabe.
Und wieso soll ich nicht mit C++ Augen messen? Es geht doch gerade darum, ob ein GC ein Fluch oder Segen ist. Ich sehe, wie sauber Memory-Management in C++ arbeitet, komplett ohne GC. Und daran messe ich GC-Sprachen.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige