Valeur VS Types de référence lors de l'utilisation d'interfaces dans C #

Conversion d'une structure en une interface provoque la boxe. Appeler implicitement implémenté Le membre sur une structure ne provoque pas de boxe: xxx

ici Dans votre cas, si vous pouvez travailler avec implication / appel implicite, vous êtes mieux à l'abri avec la structure depuis que vous en évipérez;

(a) boxe

(b) Aucun débit de mémoire supplémentaire (qui est applicable sur n'importe quelle allocation de type de référence).

Si type FOO Implements ibar , il existe deux façons par lesquelles les membres de ibar peuvent être utilisés sur une instance de Foo :

• Une référence à l'instance (pour les types de classe) ou à une référence à un objet de tas détenant une copie de l'instance (pour les types de valeur) peut être stockée dans une variable de type ibar

• L'instance (pour les types de valeur) ou une référence à celle-ci (pour les types de classe) peut être stockée dans une variable (ou un élément de champ, un élément de réseau ou un autre emplacement de stockage) d'un type générique qui est limité à ibar .

  Un emplacement de stockage d'un type de classe ou de type interface conserve une référence à un objet de démarrage ou null . Un emplacement de stockage d'une valeur de valeur primitive tiendra une collection de bits représentant sa valeur. Un emplacement de stockage d'un type de valeur non primitive conserve le contenu concaténé de tous ses champs d'instance publique et privé. Un emplacement de stockage d'un type générique t tiendra une référence de tas si t est un type de classe ou un type d'interface, une collection de bits représentant une valeur primitive si t est un type de valeur primitive ou les valeurs concaténées d'un fichier t si t est un type de structure; Cette détermination est basée sur le type réel de t , et non sur aucune de ses contraintes.

  retour à Types FOO et ibar < / code>, stockage d'un foo dans un ibar entraînera la création d'un nouvel objet de tas qui tiendra le contenu concaténé de tous les domaines public et privé de FOO et stockez une référence à cet objet de tas dans ibar . Cet objet de tas va ensuite se comporter comme tout autre objet de tas , plutôt que comme un emplacement de stockage de type valeur. Avoir des choses qui se comportent parfois comme des types de valeur et parfois comme des types de classe peuvent être déroutants; Il est préférable d'éviter une telle sémantique mixte lorsque cela est possible.

  L'heure principale peut être utile qu'une structure de mise en oeuvre d'une interface est dans des cas où l'utilisation suivra le deuxième modèle ci-dessus. Par exemple, on pourrait avoir une méthode: xxx

  dans cette situation, si on devait appeler comteUniquethings (4, 6, 6) , le Système pourrait appeler le Iequatable .equals (System.int32) Méthode directement sur les paramètres transmis de type System.int32 . Si la méthode avait été déclarée au lieu d'être déclarée: xxx

  alors l'appelant devra créer un nouvel objet de tas pour contenir la valeur int32 4, une seconde Pour contenir la valeur 6, un tiers qui tiendrait également la valeur 6, et il faudrait alors passer des références à ces objets à la méthode compteur . Icky.

  La création d'objets de tas a un certain coût. Si vous faites quelque chose d'un type de valeur, vous éviterez la nécessité de créer des objets de tas pour maintenir la grande majorité des cas, cela peut être une grosse victoire. Si chaque instance créée nécessiterait la création d'un objet de démarrage pour contenir une copie, cependant (par exemple, une variable de type interface), l'avantage de type valeur s'évaporerait complètement. Si les instances nécessiteraient en moyenne la création de plusieurs objets de démarrage pour contenir des copies (chaque fois qu'un type est converti du type de tas sur le type de valeur et le dos, une nouvelle instance sera requise), à ​​l'aide des types de valeur peut être beaucoup moins élevé. efficace que la construction d'une instance de type de classe à quel code pourrait transmettre une référence.