Changer la valeur d'un élément dans une liste de structures

Question

J'ai une liste de structs et je veux changer un élément. Par exemple :

MyList.Add(new MyStruct("john");
MyList.Add(new MyStruct("peter");

Maintenant je veux changer un élément :

MyList[1].Name = "bob"

Cependant, chaque fois que j'essaie de le faire, j'obtiens l'erreur suivante :

Impossible de modifier la valeur de retour de 'System.Collections.Generic.List.this[int]' car ce n'est pas une variable

Si j'utilise une liste de classes, le problème ne se produit pas.

Je suppose que la réponse a à voir avec le fait que les structs sont un type de valeur.

Donc, si j'ai une liste de structs, devrais-je les traiter comme lecture seule? Si j'ai besoin de changer des éléments dans une liste, alors je devrais utiliser des classes et non des structs?

Answer 1

Ne tout à fait. Concevoir un type en tant que classe ou struct ne doit pas être motivé par votre besoin de le stocker dans des collections :) Vous devriez plutôt vous concentrer sur les 'sémantiques' nécessaires

Le problème que vous rencontrez est dû aux sémantiques des types de valeur. Chaque variable/référence de type de valeur est une nouvelle instance. Lorsque vous faites

Struct obItem = MyList[1];

ce qui se passe, c'est qu'une nouvelle instance de la struct est créée et que tous les membres sont copiés un par un. Ainsi, vous avez un clone de MyList[1] c'est-à-dire 2 instances. Maintenant, si vous modifiez obItem, cela n'affecte pas l'original.

obItem.Name = "Gishu";  // MyList[1].Name reste "peter"

Maintenant, accrochez-vous pendant 2 minutes ici (Cela prend un certain temps à avaler.. cela a été le cas pour moi :) Si vous avez vraiment besoin que des structs soient stockées dans une collection et modifiées comme vous l'avez indiqué dans votre question, vous devrez faire en sorte que votre struct expose une interface (Cependant cela entraînera le boxing). Vous pourrez ensuite modifier la struct réelle via une référence d'interface, qui se réfère à l'objet boxé.

L'extrait de code suivant illustre ce que je viens de dire ci-dessus

public interface IMyStructModifier
{
    String Name { set; }
}
public struct MyStruct : IMyStructModifier ...

List obList = new List();
obList.Add(new MyStruct("ABC"));
obList.Add(new MyStruct("DEF"));

MyStruct temp = (MyStruct)obList[1];
temp.Name = "Gishu";
foreach (MyStruct s in obList) // => "ABC", "DEF"
{
    Console.WriteLine(s.Name);
}

IMyStructModifier temp2 = obList[1] as IMyStructModifier;
temp2.Name = "Now Gishu";
foreach (MyStruct s in obList) // => "ABC", "Now Gishu"
{
    Console.WriteLine(s.Name);
}

J'espère que cela vous aide. Bonne question.
Mise à jour: @Hath - tu m'as fait vérifier si j'avais négligé quelque chose d'aussi simple. (Ce serait incohérent si les propriétés setter ne le faisaient pas et les méthodes le faisaient - l'univers .Net est toujours équilibré :)
La méthode setter ne fonctionne pas
obList2[1] renvoie une copie dont l'état serait modifié. La struct d'origine dans la liste reste non modifiée. Donc l'ensemble via une interface semble être la seule façon de le faire.

List obList2 = new List();
obList2.Add(new MyStruct("ABC"));
obList2.Add(new MyStruct("DEF"));
obList2[1].SetName("WTH");
foreach (MyStruct s in obList2) // => "ABC", "DEF"
{
    Console.WriteLine(s.Name);
}

Answer 2

MaListe[1] = new MaStructure("bob");

Les structs en C# doivent presque toujours être conçus pour être immuables (c'est-à-dire, ne pas avoir de moyen de modifier leur état interne une fois qu'ils ont été créés).

Dans votre cas, ce que vous voulez faire est de remplacer l'ensemble du struct dans un indice de tableau spécifié, pas essayer de modifier simplement une seule propriété ou un champ.

Answer 3

Ce n'est pas tant que les struct sont "immuables".

Le vrai problème sous-jacent est que les structs sont un type de valeur, et non un type de référence. Donc, lorsque vous extrayez une "référence" de la struct de la liste, cela crée une nouvelle copie de toute la struct. Donc, les modifications que vous apportez concernent la copie, et non la version originale dans la liste.

Comme le mentionne Andrew, vous devez remplacer l'ensemble de la struct. À ce stade, je pense cependant que vous devez vous demander pourquoi vous utilisez une struct en premier lieu (au lieu d'une classe). Assurez-vous de ne pas le faire pour des préoccupations d'optimisation prématurée.

Answer 4

Il n'y a rien de mal avec les structs qui ont des champs exposés, ou qui permettent la mutation via les setters de propriété. Les structs qui se mutent eux-mêmes en réponse aux méthodes ou aux accesseurs de propriété, en revanche, sont dangereux car le système permettra que des méthodes ou accesseurs de propriété soient appelés sur des instances de struct temporaires; si les méthodes ou accesseurs apportent des modifications à la struct, ces modifications finiront par être ignorées.

Malheureusement, comme vous le notez, les collections intégrées dans .net sont vraiment faibles pour exposer les objets de type valeur qu'elles contiennent. Votre meilleur choix est généralement de faire quelque chose comme :

  MyStruct temp = myList\[1\];
  temp.Name = "Albert";
  myList\[1\] = temp;

Un peu ennuyeux, et pas du tout sûr avec plusieurs threads. Tout de même une amélioration par rapport à une Liste d'un type de classe, où faire la même chose pourrait nécessiter :

  myList\[1\].Name = "Albert";

mais cela pourrait aussi nécessiter :

  myList\[1\] = myList\[1\].Withname("Albert");

ou peut-être

  myClass temp = (myClass)myList\[1\].Clone();
  temp.Name = "Albert";
  myList\[1\] = temp;

ou peut-être une autre variante. On ne pourrait vraiment pas le savoir à moins d'examiner myClass ainsi que les autres codes qui mettent des choses dans la liste. Il est tout à fait possible que l'on ne puisse pas savoir si la première forme est sûre sans examiner le code dans les assemblages auxquels on n'a pas accès. En revanche, si 'Name' est un champ exposé de MyStruct, la méthode que j'ai donnée pour le mettre à jour fonctionnera, peu importe ce que MyStruct contient d'autre, ou peu importe ce que d'autres éléments ont pu faire avec myList avant que le code ne s'exécute ou ce à quoi ils peuvent s'attendre à faire avec après.

Answer 5

À quelqu'un de plus haut dans le fil de discussion qui a écrit ".Net universe is still balanced...":

Alors pourquoi le comportement n'est-il pas cohérent lors de l'utilisation d'un tableau ordinaire de structures? Je comprends que la raison se trouve dans l'implémentation de la liste générique mais ...