Pourquoi les entiers non signés ne sont-ils pas conformes à CLS ?

Question

Pourquoi les entiers non signés ne sont-ils pas conformes à CLS ?

Je commence à penser que la spécification de type est uniquement destinée aux performances et non à l'exactitude.

Answer 1

Toutes les langues n'ont pas le concept d'entiers non signés.Par exemple, VB 6 n'avait pas de concept d'entiers non signés, ce qui, je suppose, a motivé la décision des concepteurs de VB7/7.1 de ne pas l'implémenter également (c'est maintenant implémenté dans VB8).

Citer:

http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Le CLS a été conçu pour être suffisamment grand pour inclure les constructions linguistiques qui sont couramment nécessaires par les développeurs, mais suffisamment petites pour que la plupart des langues puissent la soutenir.De plus, toute construction de langues qui rend impossible de vérifier rapidement la sécurité du type du code a été exclue du CLS afin que toutes les langues conformes aux CLS puissent produire du code vérifiable s'ils le choisissent.

Mise à jour:Je me suis posé cette question il y a quelques années, et même si je ne vois pas pourquoi un UInt ne serait pas vérifiable en matière de sécurité de type, je suppose que les gars de CLS devaient avoir un point limite quelque part quant à quel serait le nombre minimum de base de types de valeur pris en charge.De plus, lorsque vous pensez au long terme, où de plus en plus de langages sont portés vers le CLR, pourquoi les forcer à implémenter des entiers non signés pour obtenir la conformité CLS s'il n'y a absolument aucun concept ?

Answer 2

Une partie du problème, je suppose, tourne autour du fait que les types entiers non signés en C doivent se comporter comme des membres d'un anneau algébrique abstrait plutôt que comme des nombres [ce qui signifie, par exemple, que si une variable entière non signée de 16 bits est égale à zéro , le décrémenter est requis pour donner 65 535, et s'il est égal à 65 535, alors l'incrémentation est nécessaire pour donner zéro.] Il y a des moments où un tel comportement est extrêmement utile, mais les types numériques présentent un tel comportement qui peut aller à l'encontre de l'esprit de certains langages.Je suppose que la décision d'omettre les types non signés est probablement antérieure à la décision de prendre en charge les contextes numériques cochés et non cochés.Personnellement, j'aurais aimé qu'il y ait des types entiers distincts pour les nombres non signés et les anneaux algébriques ;l'application d'un opérateur moins unaire à un nombre non signé de 32 bits devrait donner un résultat signé de 64 bits [la négation de tout autre chose que zéro donnerait un nombre négatif] mais l'application d'un moins unaire à un type d'anneau devrait donner l'inverse additif dans cet anneau.

Dans tous les cas, la raison pour laquelle les entiers non signés ne sont pas conformes à CLS est que Microsoft a décidé que les langues n'avaient pas besoin de prendre en charge les entiers non signés pour être considérées comme « compatibles CLS ».

Answer 3

Les entiers non signés ne vous rapportent pas grand-chose dans la vraie vie, mais avoir plus d'un type d'int vous fait mal, donc beaucoup de langues n'ont que des entiers chantés.

La conformité CLS vise à permettre à une classe d'être utilisée à partir de nombreuses langues…

N'oubliez pas que personne ne vous oblige à être conforme au CLS.

Vous pouvez toujours utiliser des entiers non signés dans une méthode, ou en tant que paramètres d'un privé méthode, car seule l'API publique est restreinte par la conformité CLS.

Answer 4

Les entiers non signés ne sont pas conformes à CLS car ils ne sont pas interopérables entre certains langages.