Pourquoi les int unsigned ne sont-ils pas conformes à CLS?

111

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.

c# .net unsigned-integer cls-compliant

— Doekman
source

88

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?

— Kev
source

@Kevin: Je me suis juste posé des questions sur le sujet. Votre réponse semble logique. J'aime juste penser au sujet. Je pense que c'est dommage que les types de type Pascal n'aient pas été intégrés au CLR. Mais votre argument sur les autres langages: cela n'a pas empêché IronPython d'utiliser le typage fortement dynamique (DLR) dans un CLR typé fortement statique?

— doekman

@doekman: Bien que oui, IronPython et IronRuby démontrent que le CLR peut fournir une plate-forme sur laquelle vous pouvez créer des langages à typage dynamique, le but du CLS était de fournir un ensemble de normes qui transcendent les fonctionnalités du langage et leur permettent d'interopérer avec succès et en toute sécurité. Je ne pense pas que ce qu'un langage peut faire en termes d'ajout de fonctionnalités DL est directement lié à ce qui devrait entrer dans le CLS / CTS.

— Kev

D'après ce que j'ai compris, le CLR a un type primitif d'entier 32 bits, qui a des instructions séparées pour l'ajout signé avec vérification de débordement, l'ajout non signé avec vérification de débordement et l'addition sans signe mod 2 ^ 32, etc. lorsqu'on lui demande de convertir une référence d'objet en une primitive entière de 32 bits, le CLR ne sait ni ne se soucie de savoir si le code utilisant ce nombre s'attend à ce qu'il soit signé ou non signé. Que le compilateur pense qu'un nombre soit signé ou non signé affectera généralement les instructions générées par le compilateur pour les opérations avec lui, mais c'est un problème de langage - pas de CLR.

— supercat du

23

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».

— supercat
source

Excellente explication du point de vue mathématique!

— dizarter

6

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.

— Ian Ringrose
source

16

Ils sont à peu près essentiels, si vous faites de l'arithmétique par bits.

— nicodemus13

@ nicodemus13 à quand remonte la dernière fois que vous avez vu un système d'administration d'entreprise qui avait une arithmétique par bit dans son domaine problématique? (Par exemple, le genre de logiciel que les programmeurs VB.NET écrivent)

— Ian Ringrose

38

Tout ce qui a une somme de contrôle utilisera l'arithmétique au niveau du bit, c'est assez courant, et il me semble étrange de faire glisser toutes les autres langues vers le bas, car VB ne supportait pas les entiers non signés. .NET est également censé être générique, pas seulement pour les rédacteurs VB d'applications LOB. Quand vous dites «1 type d'int», vous ne pensez pas qu'avoir byte, short, int, long est aussi une douleur? Je ne vois pas vraiment pourquoi signer est plus gênant.

— nicodemus13

5

Les entiers non signés ne sont pas conformes CLS car ils ne sont pas interopérables entre certaines langues.

— Bryan Roth
source