spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Bitte sage doch einfach, wofür du das genau verwenden willst. (Sehr wahrscheinlich wird es sich besser lösen lassen, als es bisher der Fall ist.)

Was heißt "egal welche Ressource"? Speicherst du auch Grafik- und Sounddaten in dieser Datei ab?
Eigentlich sollte es reichen, nur die Informationen zu speichern, die sich ändern können, bzw. anhand derer die Spielsituation wiederhergestellt werden kann. Das heißt, dass nicht auch ausnahmslos alles gespeichert werden muss.

Zitat von »Toemsel«

Zitat von »Legend«

Abgesehen davon würde ich dynamic als unsauber und schwer wartbar bezeichnen.
Definitiv ist es in der Benutzung arschlahm und für Reflection braucht man es nicht.
(Ja, das ist eine Funktionalität die ich aus C# rausschmeißen würde, wenn ich könnte)

Richtig angewendet erspart das dynamic Schlüsselwort viel Zeit und Aufwand. JungleProgger hat übrigens mit dem dynamic object direkt ins schwarze getroffen.
Nicht existierende Properties werden zur Laufzeit generiert, fall eine Versionsinkompatibilität auftreten sollte. Aber ich denke du hast für deine Aussage sicherlich triftige Gründe, die ich gerne erfahren möchte.

Ja, sehr viel COM Interop auf der Arbeit und eine ganze Menge an Interop-Assemblies bei denen viele Methoden in C# nur ein dynamic zurückliefern. Zugegegeben, durch COM Interop ist manches vielleicht noch schlimmer, als bei der Benutzung von dynamic in reinem C# Code.
Aber dynamic heißt als Anwender dieser Komponenten dann:

- Keinerlei Hilfestellung durch Intellisense
- Was die Performance angeht, nach meinen Erfahrungen: Bei einer Funktion, die wenig tut, ist ein Methodenaufruf mit Hilfe von dynamic mal um den Faktor 20 langsamer als wenn man das Objekt in das richtige Interface castet und an diesem den selben Aufruf tätigt. Und wenn man viele Funktionen aufzurufen hat, macht sich das irgendwann auch bemerkbar.
- Und wenn alles schief läuft bekommt einen sehr schnell einen schönen FatalExecutionEngineError der einem die Applikation runterreißt. Okay, diesen Fehlertyp gab es vorher auch schon. Aber mit dynamic wird er schnell zum Regelfall.

Das Properties zur Laufzeit erzeugt werden ist mir hingegen in der Tat neu. Mein Verständnis davon war, dass sich hinter dieser dynamic Referenz nach wie vor das normale Objekt befindet, und wenn man eine nicht existente Property benutzen will gibt es zur Laufzeit Probleme. Das wäre auch konsistent mit dem Verhalten in diesen Beispielen: http://msdn.microsoft.com/de-de/library/dd264741.aspx

@JungleProgger: Sorry, aber bei dynamic bin ich lieber ganz schnell dabei auf die Nachteile hinzuweisen. Dieses Keyword ist für mich eine der schlechtesten Erweiterungen zu C# die Microsoft je gemacht hat. Und um Abzufragen welche Properties ein Objekt zur Laufzeit hat, brauchst du es nicht.

Du loopst doch durch obj.GetType().GetProperties(), zumindestens war das einer der Vorschläge aus diesem Thread. GetType ist an jedem object vorhanden. Und jede andere Klasse ist direkt oder indirekt von object abgeleitet. Daher reicht object.

Die Sachen sind doch dann nicht unbekannt. Es handelt sich um Datei-Eigenschaften. Diese haben einen Schlüssel und einen Wert. Dafür brauchst Du folglich kein dynamic object, sondern ein Dictionary<string,string>.