intérêt des structures

Bonjour à tous.

Je n'utilise jamais les structures, je ne les aiment pas pour des raisons que je liste plus bas.

Mais j'ai peut-etre bafoué une régle elementaire ; ne regarde pas le probleme sous le bon angle!?!?

Pourriez vous me convaincre que les structures, ca n'est pas si mal que çà, voir indispensable dans certains cas?

Quelques raisons pour lesquels je n'utilise jamais de structure :

• Avec les structures c'est lent : on ne travaille que par recopie, jamais par référence. Du coup : copie de donnée + construction/destruction à gogo !
• Les structures, ca bouffe de la ram inutilement : toujours pour la meme raison
• On ne peut pas partager une instance de structure : avec une classe j'ai le choix de cloner ou pas l'objet; avec une structure tout le monde a son propre exemplaire. On nous apprends qu'il est dangereux de faire du copier/coller dans du code (premier paragraphe d'un quelconque chapitre sur l'heritage), et avec les structure tout n'est que copie copie copie...
• Une structure n'est pas nullable : cela nous oblique à faire une instance statique qu'on appelle "Null" ou "Empty", encore de la ram consommée pour rien.

Bonjour à toi.

Les structures n'ont finalement qu'un seul avantage : elles sont légères. Pas d'allocation de mémoire (son espace est une partie de celui de son parent et a été alloué en même temps que dernier), donc pas d'intervention du GC, pas de déréférencement additionnel (si toto est une classe, lire toto.x nécessite d'aller chercher toto dans la mémoire, tandis que si toto est une structure ses données sont déjà dans l'espace de this, ou dans la pile pour une variable locale), pas de surcharge mémoire (toute instance de classe a un header de 12 octets alors qu'une structure n'a rien de tel), pas de compteur de références à modifier à chaque assignation, etc.

De plus, certains des inconvénients que tu cites peuvent aussi être des avantages : ainsi le fait qu'une valeur soit recopiée. Pour certains algorithmes, c'est du pain béni. Si tu songes par exemple à un algo récursif qui examinerait tous les chemins d'un arbre et aurait, à chaque noeud, besoin de manipuler et modifier quelques vecteurs avant de les transmettre au noeud suivant. Quand par la suite l'algo sera amené à revenir aux noeuds précédents, les structures vecteurs transmis à ces noeuds n'auront pas été modifiés. Pour en faire autant avec des classes il aurait fallu, à chaque noeud, créer une nouvelle instance : un parcours d'un arbre relativement simple générerait ainsi des centaines de milliers d'instances, soit un fort stress pour le GC. Avec les structures, tout est resté dans la pile, un espace de taille fixe.

Enfin, quelques remarques sur tes reproches :
* Sur la consommation de ram, les structures ont plutôt un effet positif : une référence prend déjà 8 octets sur un processeur 64-bits et une structure est typiquement de la même taille (MS recommande les classes quand on excède 8 octets même si c'est plutôt une mauvaise règle : la taille compte fortement mais n'est pas le seul critère).
* Copie de données à gogo, oui, mais c'est insignifiant. Et puisqu'il faut aussi copier les références, voir ma remarque précédente. Quant aux constructeurs, tu n'es pas toujours obligé de les appeler et ils sont typiquement légers et "inlinés".
* J'ai montré que dans certains cas le passage par copie était un comportement intéressant.
* Tout n'a pas besoin d'être nullable. Il est d'ailleurs regrettable qu'on ne puisse pas faire de classe non-nullable, c'est une reproche souvent adressé à C#.

Pour conclure je dirais que les structures occupent une niche mais que, dans ces niches, elles peuvent être des atouts extrêmement précieux pour doper les performances, réduire la consommation mémoire ou améliorer le code. Et j'ajouterai qu'il ne faut surtout pas sous-estimer le coût de l'instanciation d'une classe, qui réclame un enregistrement dans les structures de données thread-safe du GC.

Citation:

---

Une structure n'est pas nullable

---

Il existe le type Nullable
http://www.meziantou.com/c-nullable/

En complément de ce qui a été dit plus haut: prend le Datetime, ou Int32. Ce sont des objets immutable, et légers. S'il n'étaient que des types référence, comme en java, ca veut dire qu'une liste de 1000 int nécessiterait la création de 1000 objets, dont le GC devrait se charger. Alors que là, une List<int> de 1000 éléments contient directement ces éléments contigus en mémoire, ce qui diminue l'empreinte mémoire totale tout en améliorant les perfs de lecture et d'écriture. Et comme le dit DonQuiche, ils sont non nullable, ce qui fait des vérifications en moins dans le code à faire.

Mais il est vrai qu'un dev .Net a rarement besoin de créer des structs. Les cas d'école sont les nombres complexes (du style a+ib, sur lesquels on surcharge les opérateurs courants *, +, -, ...), les clés composites (comme une paire de int, par exemple), les types "Money" (une paire decimal + enum ou string), ... En 5 ans de dev pro C#, j'ai du en écrire 3 ou 4 tout au plus :aie:

Merci pour vos réponses avisées.

DonQuiche, tu m'a fortement troublé, ta réponse est vraiment très interressante :mrgreen:

J'ai besoin de relire tout ca pour bien l'assimiler meme si je pense avoir compris...
Je reviendrai surement vous poser une ou deux questions sur le sujet apres avoir approfondi le sujet si vous etes ok.

Sinon j'ai découvert (par hasard) une syntaxe qui m'etait inconnue jusqu'alors. Elle semble justement en rapport avec le sujet:

Code:

---

1 2 3 4 5

{ int? x; if(x.HasValue) ///// }

---

que fait ce "?" ?

int? = Nullable<int>
C'est à dire un entier qui peut valoir null

oops :oops: juste ce dont parle l'article donné par meziantou un peu plus haut , honte à moi :oops:

Je vais aller dormir 8-)

Citation:

---

Envoyé par giova_fr

DonQuiche, tu m'a fortement troublé

---

:oops:

Ma foi, si j'ai pu répondre à tes questionnements sur le sujet, tant mieux, content d'avoir pu t'être utile. :)