Laden...

GetEnumerator für die Fields/Properties eines struct

Erstellt von Reflexer vor 9 Jahren Letzter Beitrag vor 9 Jahren 1.029 Views
R
Reflexer Themenstarter:in
3 Beiträge seit 2014
vor 9 Jahren
GetEnumerator für die Fields/Properties eines struct

Hallo,

ich habe ein Problem mit einem Struct.

Ich habe in einer Static Class ein Public Struct.

static class GlobVar
{
    .......    
    public struct scWerte
    {
        public string Wert1;
        public string Wert2;
        public string Wert3;
        public string Wert4;
    }
    ........
}

Wo und wie muss ich einen Getenumerator deklarieren, damit ich über die Variablen des structs iterieren kann?

GlobVar.scWerte scTest = new GlobVar.scWerte();
.......
foreach(string strTmp in scTest)
{......}

Vielen Dank für eure Mühen

16.807 Beiträge seit 2008
vor 9 Jahren

Das geht so gar nicht; dafür ist der Enumerator auch nicht gedacht.
Der Enumerator braucht eine Collection, in der er mit MoveNext durch gehen kann. Das funktioniert aber weder mit Feldern noch mit Properties.

Eine statische Klasse für globale Variablen hört sich jetzt auch nicht wirklich sauber an.
Was hast Du vor?

A
350 Beiträge seit 2010
vor 9 Jahren

Wenn ich glaube, dass du das vorhast was du geschrieben hast, geht das nur per Reflection.

type.GetType().GetFields(BindingFlags.Instance | BindingFlags.NonPublic)

Type.GetFields Method

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo Reflexer,

Der Enumerator braucht eine Collection

so steht es im Prinzip auch in der MSDN Doku. Doch Collection ist hier sehr weit gefasst und keineswegs beschränkt auf Collections wie sie in System.Collections.Generic implementiert sind. Es ist nicht mal gesagt, dass die Werte überhaupt in irgendeiner Datenstruktur vorliegen. Im Grunde kann man über beliebige gleichartige Werte enummerieren.

Sogar welche, die erst durch den Enumerator generiert werden. Zum Beispiel liefert Enumerable.Range eine "Sequenz von ganzen Zahlen in einem angegebenen Bereich", also IEnumerable<int> für das man wiederum einen IEnumerator<int> abrufen kann, der wiederum erst bei MoveNext den aktuellen Wert (Current) um eins erhöht. Der RangeIterator enthält also zu keinem Zeitpunkt alle Werte des Bereichs im Speicher, sondern nur den jeweils aktuellen.

Lange Rede, kurzer Sinn: Natürlich kann man auch über die Fields oder Properties eines Structs enummerieren, z.B. so wie das Ahrimaan vorgeschlagen hat oder auch über eine Statemaschine, die hardcodiert das jeweils nächste Field/Property liefert. Eine Statemaschine hat den Nach- und evtl. gleichzeitig Vorteil, dass nur über genau die Felder enummeriert wird, die hardcodiert sind und nicht automatisch über welche, die später bei der Wartung des Codes hinzukommen.

Allerdings solltest du mal in [FAQ] Variablennamen zur Laufzeit zusammensetzen schauen. Wenn du also eigentlich wirklich eine Art Liste hast, dann solltest du diese nicht als Fields Wert1, Wert2, ... WertN sondern eher als List<String> speichern. Reflection sollte man also keinesfalls dafür missbrauchen, auf durchnummerierte Fields zuzugreifen.

Anderseits gibt es durchaus gute Gründe, (per Reflection) über alle Felder eines Stucts oder auch eines normalen Objekts zu enummerieren, z.B. wenn man es serialisieren will.

herbivore

2.078 Beiträge seit 2012
vor 9 Jahren

Nur so als kleine Rand-Info:

Eine Struktur in einer Klasse?

Meistens passt für die Anforderung eine Klasse ganz gut, eine Struktur ist gar nicht nötig oder sogar ungünstig.
Und dann die Verschachtelung: Ich sträube mich schon davor, Klassen zu verschachteln (auch wenn es manchmal sinnvoll sein kann), aber eine Struktur in einer Klasse? Finde ich gar nicht gut.

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo Palladin007,

über nested classes - oder hier eben eine nested structure - kann man sicher geteilter Meinung sein. Und richtig ist auch, dass man dies nur in seltenen Fällen sinnvoll einsetzen kann. Aber ohne den Hintergrund zu kennen, kann man m.E. nicht per se sagen, dass eine geschachtelte Klasse oder Struktur schlecht ist. Es gibt durchaus (einige wenige) sinnvolle Anwendungen dafür.

Allerdings sollten wir das hier nicht vertiefen. Das wurde im Forum und im Netz ausführlich diskutiert.

herbivore