double sum = 0;
foreach (var i in values)
sum += i;
return sum / values.Length;

on fait sum += i / values.Length ! Sinon sum dépasse double.max et les fusées s’écrasent…
(c) Barrios

;)

J’ai une remarque / correction à apporter au sujet des varargs en C++.

> Bah c’est encore plus moche, et plus contraignant. Rappelez-vous :
> …
> La principale différence est finalement assez subtile on n’utilise pas explicitement
> un tableau, mais on fournit un pointeur vers le début de la liste d’arguments.

Déjà je trouve la syntaxe du C++/CLI bien plus moche, mais ce n’est qu’une affaire de goût.

Je voulais insister sur le fait que même si la syntaxe est proche, le varargs du C++ et du .NET sont deux choses très différentes.

En C++ (ISO) varargs n’est pas un tableau du tout ! Le méthode joue avec le pointeur de pile (SP = stack pointer). En particulier on ne parcourt pas les arguments par une arithmétique simple du genre adrr = base + n * taille. Il faut sommer la taille des objets stockés sur la pile plus du padding sur certaine architecture pour des histoires d’alignement d’adresse et tout ça…
L’utilisation de macros qui masquent cette réalité est requise justement parce que le calcul dépend de la machine qui exécutera la chose.
Bref, ce n’est pas un tableau.

Le varargs en Java ou en C# a repris l’idée de fonctions à nombre variable d’arguments, mais on lieu de placer des choses de tailles diverses sur la pile, on passe TOUJOURS un tableau. C’est-à-dire qu’on stocke sur la pile une référence sur un objet bien fichu et typé. Ces langages (Java, C#, etc.) permettent d’écrire librement les arguments mais on devine bien que le compilateur va réécrire ce bout de code pour instancier un tableau. C’est du sucre syntaxique.

Cyril Martin (alias mcoolive).

J’aimerai, tant qu’à y être ajouter une ligne ou deux pour parfaire l’inutilité avouée de ce post:
“Bah c’est encore plus moche” [va_xxx en C++ pas CLI]; oui, je te l’accorde c’est laid… mais C++ s’évite un downcast disgracieux dans le cas ou les paramètres sont de types différents, bien que ne connaissant C# qu’au travers de ce blog – et si je ne m’abuse – en C#, le type passé dans ces cas la est souvent params Object[]… downcast obligatoire.
Je ne sais pas si le mot clé __refvalue s’évite ce downcast (il le pourrait) mais ça pourrait être l’un de ses -nombreux- intérêts. (?)

Pour parfaire l’inutilité de mon commentaire -que j’avais d’ailleurs promis – et pour rester dans l’esprit de l’article original, je note que souvent, dans les cas où le type des paramètres varie, le test sur le type doit être fait directement ou indirectement; ça ou un downcast…

je vous laisse

adieu

Du coup, je me suis dit que ça ferait un bon post rigolo pour janvier. Mais il semblerait que je sois passé sans m’en rendre compte du “lol saviez-vous que ?” à “mangez mon gros post à faible valeur ajoutée”.

Cependant, il faudra probablement qu’un jour nous gérions ça aussi dans Cecil.Decompiler, comme ce bon Reflector !

Mais je me demande comment tu es venu à creuser ce sujet ? C’était pour Cecil.Decompiler ?

@+