spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Schorsch«

Ganz ehrlich, sicherlich ist das mal interessant und auch spannend über so Zeug wie hier zu sprechen, aber ich behaupte der Alltagsprogrammierer hier wird das meiste davon nicht brauchen.

Was ist denn für dich ein Alltagsprogrammierer? Derjenige, der all die supereasy Crapware für Handys, Websites, Photodruck & Co. schreibt, die bei jedem 4. Klick mit Verlust sämtlicher Daten droht und bei jedem 8. Klick mehrminütige Denkpausen einlegt?

Zitat von »Schorsch«

Ich behaupte wenn de_struktor ein Spiel schreibt wird er sich nicht groß um Ressourcenmanagement für Texturen kümmern müssen. Der Content Manager von XNA kümmert sich für ihn darum und sein Speicher wird ausreichend sein. Natürlich davon ausgegangen dass es sich hier um kein Spiel im High End RPG Style mit 1000en Texturen handelt.

Spiele gehören mitunter zu den ressourcenintensivsten Anwendungen überhaupt; unabhängig davon, ob das in diesem Fall zutrifft, ist Ressourcenverwaltung eine elementare Kernkompetenz, ohne die Programmierer nachfolgende Generationen schlussendlich nur mit Sondermüll belasten, wie er uns schon heute in all unseren Software-Ökosystemen in unerträglichen Dosen das tägliche Arbeiten zur Hölle macht.

Zitat von »Schorsch«

Ich selbst habe ja nun einige Jahre mit C# arbeiten dürfen/müssen (eher dürfen) und habe selbst nur sehr selten IDisposable benötigt. C# kann durch den GC auch wirklich ätzend werden, wenn man es dann wirklich benötigt. Meiner Meinung nach aber nicht unbedingt weil der Speicher nicht schnell genug freigegeben wird (ganz ehrlich was schreibt ihr bitte für Anwendungen ) sondern eher weil bestimmte Ressourcen nicht schnell genug freigelegt werden.

Um nichts anderes geht es hier, es geht ausdrücklich nicht um Speicher, siehe Post 1.

Zitat von »Schorsch«

Da wäre zum Beispiel Netzwerk und Sockets ein Beispiel was ja schon angesprochen wurde. Ich denke solange ich Ressourcen nicht selbst manage (unmanaged resources) brauche ich mir in den meisten Fällen bei C# weniger Gedanken um Dispose etc machen.

Du musst aber eben selbst managen, sobald du aus vorgefertigten Umgebungen wie XNA (das meines Wissens nach auch nicht mehr weiterentwickelt wird) rausgehst. Und selbst in solchen Umgebungen findest du Klassen, die IDisposable implementieren.

Zitat von »Schorsch«

Das schöne an .Net ist doch dass sich um sowas gekümmert wird.

Nein, es wird sich grundsätzlich nicht implizit um andere Ressourcen gekümmert; using deckt einen Teil der Problematik mit IDisposable-Klassen ab, aber auch nur innerhalb einer Funktion.

Zitat von »Schorsch«

Als C++ Entwickler gibt man das nur ungern aus der Hand weil man sich hier halt um alles selbst kümmert, aber bei .Net ist es halt so. Und meiner Meinung nach sind selbst die Smartpointer bei C++ nicht ansatzweise so einfach wie der GC.

In C++ musst du dank "Smart Pointers" nicht selbst managen, insofern nehmen sie dir bei der Ressourcenverwaltung im Gegensatz zum C#-GC einen ganzen Batzen Arbeit ab.

Zitat von »Schorsch«

Das Problem (was ja schon angesprochen wurde) sind ja Referenzzyklen. Und die kann man sich nun mal schnell einhandeln wenn man nicht aufpasst. Dann kann man natürlich am Design schrauben und machen und tun, aber das Design zu ändern nur weil meine Referenzverwaltung sonst nicht klar kommt ist auch nicht der beste Weg.

Referenzzyklen sind meiner bisherigen Erfahrung nach ein wesentlich geringeres Problem, als man vielleicht annehmen würde. Es ist längst gängige Best Practice in allen Softwaresystemen, diese als azyklischen Graphen aufzuziehen. Das hat vor allem softwaretechnische Gründe, z.B. unabhängige Prüfbarkeit, Wartbarkeit, Reuse, Austauschbarkeit etc. Ich habe seit Jahren eine Weak-Pointer-Klasse, mit der sich solche Zyklen lösen ließen, sollten sie denn mal auftreten. Fazit: Ich habe die Klasse in all den Jahren kein einziges Mal genutzt.

Zitat von »Schorsch«

Deswegen denke ich dass das hier alles eine Sache ist bei welcher man stark zwischen Sprachen unterscheiden kann. Wenn man C++ und C# vergleichen möchte kann man auch Assembler und C vergleichen. Beide unterscheiden sich stark voneinander und haben eigentlich auch andere Anwendungszwecke.

Der Vergleich hinkt aber gewaltig. C++ ist konzeptuell bis heute eine der stärksten Hochsprachen, die leider an ganz anderen Problemen wie der altbelasteten Syntax, der unglücklichen Grammatik, des veralteten Modulsystems etc. leidet. Ein Vergleich der Konzepte von C++ und C# ist auf keinen Fall unsinnig, weil beide Sprachen sehr ähnliche Ziele verfolgen, nämlich möglichst fehlerarme Programmierung. Gerade in Bezug auf Ressourcenverwaltung und Fehlerbehandlung erreicht C# in meinen Augen bis heute nicht die Vollständigkeit, Eleganz und Konsequenz von C++.