Pourquoi les entiers non signés ne sont-ils pas conformes à CLS?
Je commence à penser que la spécification de type est juste pour les performances et non pour l'exactitude.
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 poussé les concepteurs de VB7 / 7.1 à ne pas l'implémenter également (il 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 de langage couramment nécessaires aux développeurs, mais suffisamment petit pour que la plupart des langages puissent le prendre en charge. De plus, toute construction de langage qui rend impossible la vérification rapide de la sécurité de type du code a été exclue du CLS afin que tous les langages conformes CLS puissent produire du code vérifiable s'ils le souhaitent.
Mise à jour: Je me suis posé des questions à ce sujet 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 de coupure quelque part pour savoir quel serait le minimum de base. nombre de types de valeur pris en charge. Aussi, lorsque vous pensez à plus long terme où de plus en plus de langues sont portées vers le CLR, pourquoi les forcer à implémenter des ints non signés pour obtenir la conformité CLS s'il n'y a absolument aucun concept, jamais?
Une partie du problème, je soupçonne, 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 , il est nécessaire de le décrémenterpour 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 peut-être 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 séparés pour les nombres non signés et les anneaux algébriques; l'application d'un opérateur moins unaire à un nombre 32 bits non signé devrait donner un résultat signé 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 produire 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 ne devaient pas prendre en charge les entiers non signés pour être considérées comme «compatibles CLS».
la source
Les int non signés ne vous rapportent pas beaucoup dans la vraie vie, mais avoir plus d'un type d'int est douloureux, donc beaucoup de langues n'ont chanté que des ints.
La conformité CLS vise à permettre à une classe d'être utilisée à partir de nombreux langages…
N'oubliez pas que personne ne vous oblige à être conforme CLS.
Vous pouvez toujours utiliser des entiers non signés dans une méthode ou en tant que paramètres d'une méthode privée , car c'est uniquement l'API publique que la conformité CLS limite.
la source
Les entiers non signés ne sont pas conformes CLS car ils ne sont pas interopérables entre certaines langues.
la source