[C#] Dictionary

[BeRsErKeR]

Mal eine ganz dumme Frage. Kann man in C# über den Index-Operator beispielsweise eines Dictionaries direkt Member des Value-Objekts ändern?

Beispiel:

Code: Alles auswählen

Dictionary<int, Point> foo = new Dictionary<int, Point>();
foo.Add(0, new Point(10, 10));

foo[0].X = 5;

Also ich bekomme hier (letzte Zeile) vom Compiler eins auf den Deckel.

Der Rückgabewert "System.Collections.Generic.Dictionary<int,System.Drawing.Point>.this[int]" kann nicht geändert werden, da er keine Variable ist.

Soweit so unschön. Nun die Frage ob man das irgendwie schön lösen kann.

Prinzipiell ist ja folgendes möglich:

Code: Alles auswählen

foo[0] = new Point(5, foo[0].Y);

Nur möchte ich nicht immer ein neues Objekt erstellen. Dachte das kann man vielleicht irgendwie eleganter lösen.

[Artificial Mind]

Nein das geht nicht anders.
In C# sollte man deswegen bei Value Types sehr vorsichtig sein.

Nachtrag: und komm nicht auf die Idee ein eigenen Point-Struct zu schreiben, das eine Setter-Methode oder Property hat, denn das zurückgegebene Objekt ist eine Kopie, kein Original. Bin ich vorgestern erst drauf reingefallen ;)

[dot]

Nein das geht leider nicht. Das geht afaik nur bei Arrays. Du könntest einen Setter schreiben, dann gehts evtl., bin mir aber nicht ganz sicher, is schon länger her...

EDIT: Ok, nachdem der Indexer ja nur ein Value zurückgibt, wird das wohl auch net helfen...

[Artificial Mind]

Nein das geht leider nicht. Das geht afaik nur bei Arrays. Du könntest einen Setter schreiben, dann gehts evtl., bin mir aber nicht ganz sicher, is schon länger her...

EDIT: Ok, nachdem der Indexer ja nur ein Value zurückgibt, wird das wohl auch net helfen...

Das ist das was in meinem Nachtrag drinsteht, es geht definitiv nicht mit einem Setter ;)

Ich hatte das für die Vertex-structs gemacht, um die Daten zu setzen und sicherlich 2 Stunden mit Debuggen verbracht, wieso meine Vertices nicht gezeichnet werden ;)

[dot]

Für Vertices würd ich zu Arrays raten ;)

[Artificial Mind]

Aber nicht in der Generierungs-Phase, wenn ich die Anzahl noch nicht kenne.

EDIT: ja, hängt halt stark von der Architektur ab - und ich mag List sehr viel lieber als arrays :)

[dot]

Ich auch, aber bei List hast du wieder das gleiche Problem wie mit dem Dictionary ;)

[BeRsErKeR]

Das ist aber ziemlich unschön wenn man ziemlich große Objekte in einem Dictionary oder anderen Container verwaltet und beispielsweise nur einen Member ändern will. Da jedes mal ein neues Objekt anzulegen kann doch nicht die Lösung sein.

[Artificial Mind]

Man sollte keine "ziemlich großen" Value-Type-Objekte haben. Dafür gibt es Klassen in C#.

[dot]

Das ist aber ziemlich unschön wenn man ziemlich große Objekte in einem Dictionary oder anderen Container verwaltet und beispielsweise nur einen Member ändern will.

Ich vermute mal, du verwendest das Dictionary eh nur als Hashtable beim Einlesen der Vertices um ein indiziertes Mesh aufzubauen!?
Wobei ich mich dann frag, in welchem Zusammenhang du da überhaupt auf dieses Problem stoßt...

Da jedes mal ein neues Objekt anzulegen kann doch nicht die Lösung sein.

Wenn du eine bessere Lösung findest, dann sags mir. Das Problem hatt ich auch schon ;)
Die Frage ist ob der C# Compiler evtl. fähig ist, entsprechend zu optimieren, sodass z.B. ein

Code: Alles auswählen

bla[i] = new blub(10, bla[i].y);

zu einem

Code: Alles auswählen

bla[i].x = 10;

wird. Ich habs nicht ausprobiert.
Generell würd heute wohl direkt den OpenGL Renderer von dem entsprechenden C# Projekt, um das es da damals ging, in C++/CLI schreiben, statt einen .NET Wrapper um OpenGL zu basteln. Wrapper sind eben wirklich nie eine gute Idee ;)

[BeRsErKeR]

Ne das ganze dreht sich nicht um Meshes. Ich bastle mir einen Map-Editor für ein 2D-Jump'n'Run in der Art von Sonic, bei dem die Maps halt nicht nur aus Tiles, sondern aus geometrischen 2D Objekten, wie Rampen, Loopings, usw bestehen. C# deshalb, weil man einfacher und schneller ein vernünftiges GUI hinbekommt. Das eigentliche Spiel wird dann in C++ geschrieben.

Geometrische Objekte sind halt über eine Liste von Punkten repräsentiert. Im Eigenschaften-Fenster solche Objekte möchte ich halt z.B. die x-Komponente eines Punktes ändern. Dabei trat das Problem auf.

Einem Punkt könnte man aber halt noch weitere Daten mitgeben, wie Farbe, Textur usw. Irgendwann wird die Struktur halt etwas größer. Und da würde ich das schon recht unschön finden. Wobei es im Map-Editor wahrscheinlich nicht so sehr ins Gewicht fallen wird.

[dot]

Ok, dann versteh ich aber nicht wofür das Dictionary. Wäre eine List nicht viel effizienter?

[Artificial Mind]

Und benutzt am besten Klassen für sowas. C# ist darauf optimiert, große Mengen von Objekten zu erstellen, da hat man nicht jedesmal den system calls overhead von einem C++-new. Da kannst du dann deine Punkte vernünftig reinpacken, du kannst sogar Properties benutzen um mit einem PropertyGrid bequem alles editieren zu können, hast Vererbung usw. usf.
Meiner Erfahrung nach gibt es wenig Situationen wo man wirklich eigene Value Types haben möchte.

[Schrompf]

... bis das erste Mal der Garbage Collector zuschlägt und durch Millionen an Kleinstobjekten waten muss :)

[Artificial Mind]

... bis das erste Mal der Garbage Collector zuschlägt und durch Millionen an Kleinstobjekten waten muss :)

Ist dir da schon wirklich mal die Performance dran kaputtgegangen? Mir noch nie und ich habe häufiger _sehr_ viele Objekte erstellt (halt 2-3 GB Ram mit kleinen Objekten voll).
Meine Erfahrungen:
C# GC hat damit kein Problem, der hat ne gute Generationenverwaltung und kriegt auch echt viele Objekte gut gemanaged und beeinflusst nicht/kaum die anderen Threads.
Java/Sun GC friert das Programm bisweilen einige Sekunden lang ein.

[BeRsErKeR]

Ok, dann versteh ich aber nicht wofür das Dictionary. Wäre eine List nicht viel effizienter?

Das Dictionary nutze ich eigentlich für eine Liste aus Polygonen. Für die Punkte verwende ich eine Liste, aber hab für das Beispiel nun Punkte genommen, zur Vereinfachung. Das Dictionary für Polygone brauche ich, weil ich sie über eine ID referenzieren will (im Editor kann man dann besser die Polygone unterscheiden) und muss sich nicht durch die Liste hangeln.