Lista struktur

Wczytuję dane z pliku linia po linii w takim formacie:
C200 12 100 1100 czyli string, double, double, double.
Powiedzmy, że nie wiem ile takich linii jest w pliku.
Zależy mi, by dynamicznie zmieniać ilość linii (dodawać, uswać), więc wybrałem listę.
Jak najlepiej przechować takie dane? Czy lista struktur to dobry pomysł?

public struct Dane
{
    public string zmienna1;
    public double zmienna2;
    public double zmienna3;
    public double zmienna4;
}

private List<Dane> mojedane = new List<Dane>();
public List<Dane> MojeDane { get { return mojedane; } set { mojedane = value; } }

Potrafię dodać elementy do listy

MojeDane.Add(new Dane { zmienna1="C200", zmienna1=12, zmienna1=100, zmienna1=1100 });

ale nie potrafię ich zmodyfikować:

MojeDane[0].zmienna1 = "C100";  

wyrzuca błąd: Cannot modify the return value of .Collections.Generic.List<WindowsFormsApplication1.Form1.Dane>.this[int]' because it is not a variable

no i ujawnily sie braki w teorii miedzy struktura, a klasa
uzyj klas, zamiast struktur, reszta kodu bedzie ok
chyba ze masz jakis pwod, aby uzywac struktur

To nie braki w teorii, tylko braki w C#.
Na przykład w Delphi taki zapis spokojnie by przeszedł.
W C# trzeba na około:

var dana = MojeDane[0];
dana.zmienna1 = "C100";
MojeDane[0] = dana;

To nie jest brak w C#, tylko brak w Twojej wiedzy.
Struktura != Klasa (w C#).
struct'y są value type, class'y są reference type
Struktury sa więc przenoszone przez wartosc, wiec w 99% miejscach sa projektowane jako IMMUTABLE.
Jeżeli kompilator dopuściłby zapis:
MojeDane[0].zmienna1 = "C100";
ktory na dobra sprawe jest poprawny, to okazaloby sie, ze:
operator this[] zwrocil kopie, jak to na struct przystalo
Ty jej zmieniles pole zmienna1
Twoja zmiana wyparowala, bo operowales na kopii

Stad komunikat, ze lewa strona nie jest pelnoprawna zmienna i trzeba ja sobie odebrac do zmiennej.
Tak wiec, podziekuj kompilatorowi za tą weryfikacje i pisanie na okolo, gdyż pewnie bledu by szukac z godzine mozna było.

ps. teoretycznie istnieją mutable structs, ale lepiej sie za nie nie zabierac jesli nie widzi sie roznic miedzy struct a class w C#..

Całe nieporozumienie wynika stąd, że do niedawna pisałem w visual basicu,
ale tam struktura to zupełnie inny twór.

spox.
Visual Basic Language Reference: Structure Statement

... The Structure statement defines a composite value type that you can customize. A structure is a generalization of the user-defined type (UDT) of previous versions of Visual Basic. For more information...

chyba, że masz na myśli VB-nie-.Net, np. VB6?

Struktury nie są immutable, to raz.
Dwa, że mógłby być wprowadzony lukier składniowy powodujący, że taka zmiana pola w strukturze byłaby równoważna wywołaniu gettera a następnie settera takiego property.
Minusem takiego rozwiązania jest to, że dla wielkich struktur byłaby to operacja powolna (dwukrotne kopiowanie całej struktury) podczas gdy nam się wydaje że zmieniamy tylko jedno pole.
Ale znowu kopiowanie dużej struktury przez jawną zmienną będzie tak samo powolne. Wtedy najlepszym rozwiązaniem jest użycie klasy zamiast struktury.

No i wprowadzając lukier składniowy zrobimy klasę ze struktury. Chyba po to są to oddzielne twory, żeby różniły się w zachowaniu i zastosowaniach.

quetzalcoatl napisał(a)

spox.
Visual Basic Language Reference: Structure Statement

... The Structure statement defines a composite value type that you can customize. A structure is a generalization of the user-defined type (UDT) of previous versions of Visual Basic. For more information...

chyba, że masz na myśli VB-nie-.Net, np. VB6?

Chodzi o vb6.

Azarien napisał(a)

Struktury nie są immutable, to raz.
Dwa, że mógłby być wprowadzony lukier składniowy powodujący, że taka zmiana pola w strukturze byłaby równoważna wywołaniu gettera a następnie settera takiego property.
Minusem takiego rozwiązania jest to, że dla wielkich struktur byłaby to operacja powolna (dwukrotne kopiowanie całej struktury) podczas gdy nam się wydaje że zmieniamy tylko jedno pole.
Ale znowu kopiowanie dużej struktury przez jawną zmienną będzie tak samo powolne. Wtedy najlepszym rozwiązaniem jest użycie klasy zamiast struktury.

Azarien: Przeczytaj jeszcze raz moja wypowiedz do ktorej sie odnosisz, i przeczytaj wszystkie slowa, lacznie z "projektowane", ktore nie przeczy temu, ze domyslnie one takie nie sa i trzeba sie o to samemu zatroszczyc. Poza tym, jeśli obstawiasz przy swoim, życzę powodzenia w modyfikowaniu-w-locie struktury zwroconej przez indexer, bez odbierania jej do zmiennej. Chyba, że marzy Ci sie, aby kompilator z linijki "bum[i].ble = 1" - jesli wykryje ze indexer/property zwraca struct - to wtedy wykona "tmp=bum[0];tmp.ble=1;bum[0]=tmp" ? To w takim razie proponuje, zebys rozwazyl przypadek, w ktorym indexer/property jest zdefiniowany jako get-only, bez settera. Przy get-only indexer/properties, dla zwracanych reference-type-objects, zapis bum[0].x = 1 jest poprawny u oczywisty. A jakby kompilator mial wg Ciebie wtedy 'sprytnie' wygenerowac kod gdy get-only indexer zwracalby valuetype a ktos by napisal taka linie?

A jakby kompilator mial wg Ciebie wtedy 'sprytnie' wygenerowac kod gdy get-only indexer zwracalby valuetype a ktos by napisal taka linie?
To chyba naturalne, nijak. Bo skoro nie można przypisać wartości do property, to nie można.