spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Verstehe. Ich habe gegenüber manuellem Speichermanagement nicht so eine ablehnende Haltung: Hat insbesondere bei dem, was Rust bedient, seine großen Stunden.

Bei Swift bin ich da eher skeptisch. Ich habe nur einmal eine Objective-C Anwendung mit (manuellem) Reference Counting entwickelt und da fand ich das echt schwierig. Gerade bei komplizierten GUI-Sachen hatte ich dann schnell mal bereits weggeräumte Sachen oder Sachen wurden nicht weggeräumt obwohl es gewünscht war. Die Fälle, die ich da hatte, dürfte Swift mit ARC auch nicht so einfach aus dem Weg räumen.

Vielleicht bin ich auch einfach zu dumm oder zu faul für die Entwicklung mit einer Non-GC-Sprache, aber ich glaube das geht dann vielen anderen auch so.

Definitiv, in Swift macht man schneller Ownership-Fehler als in C++, da stimme ich absolut zu. Manuelles Reference-Counting in Objective-C war auch die totale Hölle, weswegen es durch ARC abgelöst wurde. ARC ist auch in Swift drin, nur ist es dort wesentlich "nativer" als in z.B. Java oder C# eine unowned/weak reference zu benutzen. In letzteren beiden sieht man sie so gut wie nie und das erzeugt unweigerlich ungewollte Zyklen irgendwo, das is klar. Zyklen sind aber nicht meine Hauptsorge, die können mMn sowohl GC als auch non-GC-Sprachen prima behandeln. Probleme sind eben Ressourcen. Und die Zeitpunkte ihrer Freigabe.

Zitat von »BlueCobold«

Probleme sind eben Ressourcen. Und die Zeitpunkte ihrer Freigabe.

Und da unterscheiden sich glaube ich wirklich unsere Erfahrungswelten. Das schlimmste, was ich da kenne, sind Datenbank-Verbindungen, die nicht richtig aufgeräumt werden. Und das kann man, wie gesagt, mittlerweile wirklich äußerst angenehm abstrahieren. Mal ein Beispiel, wie weit das mittlerweile getrieben wurde: Der EntityManager ermöglicht dann den Zugriff auf die Datenbank (kennst Du ja wahrscheinlich). Wenn eine Exception fliegt, wird ein Rollback gemacht. Man muss sich um nichts kümmern. Der EntityManager wird von alleine abgeräumt usw. Befindet man sich schon in einer Transaktion, wird natürlich keine weitere geöffnet. Alles so wie man es intuitiv erwarten würde. Vielleicht kennst Du ja auch das gesamte Konstrukt schon. Findest Du das nicht auch herrlich einfach und praktisch?

Merkt ihr nicht dass ihr aneinander vorbei redet?
Ein GC ist kein Allheilmittel, ja. Es gibt Dinge bei denen er viele Probleme macht, ja. Es gibt aber auch Software die keine Sockets, Filezugriffe und andere Ressourcen benötigt. Bei der es egal ist ob Speicher direkt freigegeben wird oder eben nicht. Und ja, es gibt andere Möglichkeiten bei denen man ohne GC auskommt, das ist richtig. Bei C++ muss man sich aber tatsächlich mehr Gedanken machen. Immerhin muss ich entscheiden ob das Objekt nun besessen oder nur gekannt wird. Das ist keine riesen Sache aber zu behaupten man muss sich nicht mehr Gedanken machen ist nicht richtig.
Andererseits ist ein GC eben nicht immer die tolle Hilfe. Die schon oft angesprochenen Ressourcen werden schnell Problematisch, der fehlende Determinismus macht es in vielen Fällen auch nicht unbedingt leichter und ja es wurden ja genug Punkte genannt warum ein GC ziemlich bescheiden sein kann.

Weiterhin sollte man aber doch festhalten dass man mit Sprachen wie C++ und Java stark unterschiedlich arbeitet. Ich kann solche Dinge wie den Zyklus in der genannten Liste machen ohne mir darüber Gedanken zu machen. In C++ darf ich das so nicht, muss mir also Gedanken um Besitz machen. Reference Counting kommt mit solch einem Fall auch nicht klar, es sei denn ich löse den Zyklus händisch. Zumindest wüsste ich nicht dass es RC gibt welches mit Zyklen klar kommt. Ich finde es gibt durchaus Berechtigung für beide Welten. Ich arbeite selbst nicht mehr gern mit GC, das liegt aber an den Sachen die ich entwickle. Da stört mich der GC eben. Mag auch sein dass die Zukunft neues bringt und ein GC überflüssig wird. Das wird sich dann zeigen.
Meiner Meinung nach ist das hier genau so eine Diskussion wie die über Programmiersprachen, Betriebssysteme oder OpenGl/DirectX weil eben keiner die Seite des anderen verstehen oder akzeptieren möchte.

Zitat von »Schorsch«

Meiner Meinung nach ist das hier genau so eine Diskussion wie die über Programmiersprachen, Betriebssysteme oder OpenGl/DirectX weil eben keiner die Seite des anderen verstehen oder akzeptieren möchte.

Ich hatte jetzt nicht das Gefühl, dass ich uneinsichtig bin.

Ich stimme Deiner Einschätzung über die unterschiedlichen Problem-Welten (ich finde mann kann es schon Welten nennen) voll zu. Ich habe nichts gegen manuelles Speichermanagement per se und finde es in der entsprechenden Problemwelt völlig angemessen.

Das einzige, wovon ich kaum abrücken werde, ist Folgendes:

Zitat von »Chromanoid«

Ich glaube schon, dass man von der Popularität von GC-Sprachen auf die Häufigkeit dieser mit GC-Sprachen besser einfacher lösbaren Probleme schließen kann.

Zitat von »Chromanoid«

Ich hatte jetzt nicht das Gefühl, dass ich uneinsichtig bin.

Möglicherweise habe ich dich da falsch interpretiert. Zu deinem Punkt. Da würde ich dann eher BlueCobold zustimmen. Die Standardbibliotheken sind bei Java und C# einfach verdammt stark und das trägt denke ich stark dazu bei. Da glaube ich nicht dass es am GC liegt. Aber an sich ist das von uns beiden Spekulation. Da kommt eben vieles zusammen und am Ende liegt es vermutlich an vielen Faktoren.
Ich ärgere mich schon wieder dass ich in die Diskussion überhaupt eingestiegen bin Aber gut

Kennt ihr denn eine Sprache ohne GC, die so eine tolle Standardbibliothek mitbringt? Machen C++-Entwickler einfach lieber alles selbst? Wie gesagt ich glaube Hauptpunkte sind wirklich GC und einfaches dynamisches Linken, warum das bei "managed" Sprachen meist von Anfang an so ganz anders aussieht.

Selbst das, was man bei den OS-Entwicklern mit bekommt und sozusagen C++ mit Windows- oder Objective-C mit Apfel-Geschmack ist, finde ich stinkt meist ab gegen das, was man z.B. bei .NET bekommt.

Ich mag es ja eher, wenn nicht alles direkt mit der Standard-Bibliothek kommt, sondern diese übersichtlich ist. In D und Rust hat man alles nötige in der std, und benötigt man was extra, dann holt man es sich per Package Manager (dub, cargo). Aber da kann man sicherlich geteilter Meinung sein. Wenn alles in der std ist, hat man zumindest Qualitätssicherung.

Zitat von »Schorsch«

Immerhin muss ich entscheiden ob das Objekt nun besessen oder nur gekannt wird.

Das sollte eh schon durch das bestehende Design der Software feststehen. Wenn nicht, dann sollte man sich damit mal beschäftigen. Denn wer was besitzt oder nur kennt ist eig. ein recht wichtiger Teil der gesamten Architektur.

Zitat von »Schorsch«

Reference Counting kommt mit solch einem Fall auch nicht klar, es sei denn ich löse den Zyklus händisch. Zumindest wüsste ich nicht dass es RC gibt welches mit Zyklen klar kommt.

Das Referenz-Model von PHP z.B.: http://php.net/manual/de/features.gc.collecting-cycles.php

Zitat von »Architekt«

Das sollte eh schon durch das bestehende Design der Software feststehen. Wenn nicht, dann sollte man sich damit mal beschäftigen. Denn wer was besitzt oder nur kennt ist eig. ein recht wichtiger Teil der gesamten Architektur.

Sehe ich nicht so dogmatisch. Bei großen Anwendungen kennt man nie die gesamte Architektur in so einem Detail. Und wenn man sich sorgen muss, was man wo rein tun darf, dann ist man mit nem GC schneller bei der Sache.

Zitat von »Architekt«

Das Referenz-Model von PHP z.B.: http://php.net/manual/de/features.gc.collecting-cycles.php

Auch "GC" genannt .

Zitat von »Chromanoid«

Zitat von »Architekt«

Das Referenz-Model von PHP z.B.: http://php.net/manual/de/features.gc.collecting-cycles.php

Auch "GC" genannt .

Als Notfallsystem, falls Programmierer aus Versehen oder aus purer Faulheit Zyklen eingebaut haben, weil sie sich eben nicht mit ihrem System und deren Komponenten zu sehr auseinandersetzen wollten. Oder weil sie schlicht unfähig waren, das kommt auch vor.
Aber der GC ist eben nur als Notfallsystem da, um zyklische Referenzen aufzulösen - nicht aber für den generellen Zweck der Speicherverwaltung. Das meinte ich, als ich vor einigen Seiten sagte, dass PHP nicht gänzlich deterministisch ist.