Discussion :

[Guulh]

Bonjour à tous,

une question me titille depuis quelque temps au sujet des collections de structs.
Je m'explique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
List<MaStruct> list;
foreach(MaStruct s in list)
{
int a = s.UnePropriété;
}
 
for(int i = 0 ; i < list.Count ; i++)
{
int a = list[i].UnePropriété;
}

Y'a-t-il copie de la struct dans un cas et pas dans l'autre ? dans le cas du foreach, il me semble que oui : si je modifie s dans le corps du foreach, la collection n'est pas altérée. Dans le cas du for, la ligne "list[i].UnePropriété = 0" lance une exception car visiblement l'indexeur this[int] de List renvoie un objet non modifiable (une rvalue, si je ne me trompe).

J'ai un projet ou pour des raisons historiques, des objets qui devraient être des classes sont des structs, avec des dizaines de champs plus ou moins complexes. Et je finis par me demander si le parcours d'une collection de structs est intrinsèquement coûteux, ou s'il y a moyen de récupérer des valeurs sans pour autant recopier la struct en entier dans la mémoire associée à la fonction courante.

En espérant avoir été clair

[tomlev]

Dans le cas du for, la ligne "list[i].UnePropriété = 0" lance une exception car visiblement l'indexeur this[int] de List renvoie un objet non modifiable (une rvalue, si je ne me trompe).

Pourtant ça devrait marcher (à moins que UnePropriété soit en lecture seule, mais dans ce cas ça ne compilerait pas...)
C'est quoi l'exception ?

[Guulh]

Pourtant ça devrait marcher (à moins que UnePropriété soit en lecture seule, mais dans ce cas ça ne compilerait pas...)
C'est quoi l'exception ?

Je cite : Impossible de modifier les membres de 's', car il s'agit d'un 'variable d'itération foreach'

Ce qui signifie que pour modifier une struct dans une liste, il faut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for(int i = 0; i < liste.Count ; i++)
{
MaStruct s = liste[i]; // on copie
s.UnePropriété = 0; // on modifie
liste[i] = s; // on recopie
}

C'est aussi moche que peu performant

[tomlev]

Tu sembles mélanger exception et erreur de compilation... une exception se produit pendant l'exécution.
cf. la doc pour les erreurs du compilateur CS1654 (cas du foreach) et CS1612 (cas du for)

Ce qui signifie que pour modifier une struct dans une liste, il faut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for(int i = 0; i < liste.Count ; i++)
{
MaStruct s = liste[i]; // on copie
s.UnePropriété = 0; // on modifie
liste[i] = s; // on recopie
}

C'est aussi moche que peu performant

Oui, c'est moche... mais bon, c'était moche aussi d'utiliser des structures pour faire ce genre de chose

[Guulh]

Tu sembles mélanger exception et erreur de compilation... une exception se produit pendant l'exécution.
cf. la doc pour les erreurs du compilateur CS1654 (cas du foreach) et CS1612 (cas du for)

Certes, me suis mal exprimé Mais la doc de ces erreurs de compilation n'est ni explicite ni détaillée, malheureusement.

Mais tu vois le fond du truc ? Quand tu fais une boucle for, tu ne vas voir le contenu de la liste que quand tu demandes à évaluer liste[i], alors que je ne sais pas ce qui se passe de le cas du foreach. Je me demande dans le ce cas, avec foreach(MaStruct s in liste), que est la nature exacte de l'objet s : ça n'a pas l'air d'être une variable puisque ce n'est pas modifiable, ça n'est peut être qu'un accesseur, mais je manque peut être de vocabulaire de programmation pour saisir ce que ça peut être.

[tomlev]

Oui, je vois ce que tu veux dire...
En fait, avec foreach, l'enumerateur de la collection te renvoie des copies des objets (puisqu'ils sont de type valeur et non référence). Par contre je ne vois pas trop pourquoi il dit que ce n'est pas une variable... peut-être qu'il génère cette erreur juste pour qu'on évite de faire l'erreur de modifier une copie ?

[StormimOn]

J'ai un projet ou pour des raisons historiques, des objets qui devraient être des classes sont des structs, avec des dizaines de champs plus ou moins complexes.

Si les objets sont complexes, et donc probablement avec une taille importante, les structures ne sont plus adaptées. Les recommandations de Microsoft sont de 16 octets max je crois (2 entiers sur 64 bits par exemple).

Maintenant peut être que cela a été fait pour utiliser le passage par valeur, plutôt que par référence. Mais même si au départ c'est historique, peut être faudrait-il envisager le passage à des classes, si c'est possible.