Unsigned par rapport à des nombres signés comme indices

Question

Quelle est la justification de l'utilisation des nombres signés comme index dans .Net?

En Python, vous pouvez indexer à partir de la fin d'un tableau en envoyant des numéros de négatifs, mais ce n'est pas le cas en .Net. Il est pas facile pour .Net pour ajouter une telle fonctionnalité plus tard qu'il pourrait casser tout autre code peut-être en utilisant des règles spéciales (oui, une mauvaise idée, mais je suppose que cela arrive) sur l'indexation.

Non que j'ai jamais eu besoin de tableaux d'index sur 2.147.483.647 taille, mais je ne comprends vraiment pas pourquoi ils choisissent des nombres signés.

Peut-être parce qu'il est plus normal d'utiliser des nombres signés dans le code?

Edit: Je viens de trouver ces liens:

Les périls de non signé itération en C / C ++

longueurs et des index de mots signés

Edit2: Ok, deux autres bonnes raisons du fil Matthew Flaschen affiché:

• Des raisons historiques que c'est un c comme langue
• Interop avec c

Answer 1

Par souci de simplicité bien sûr. Vous aimez difficulté faire des calculs de taille avec ints non signés?

Answer 2

Il peut être à la longue tradition d'utiliser une valeur inférieure à 0 comme un indice non valide. Des méthodes telles que String.indexOf renvoient -1 si l'élément est introuvable. Par conséquent, doit être signé la valeur de retour. Si l'indice-consommateurs nécessiteraient des valeurs non signées, vous devez a) et b chèque) jeter la valeur pour l'utiliser. Avec des indices signés, vous avez juste besoin du chèque.

Answer 3

Unsigned n'est pas conforme CLS.

Answer 4

L'utilité principale de nombres non signés se pose lors de la composition plus grand nombre de plus petits, et vice versa. Par exemple, si l'on reçoit quatre octets non signés d'une connexion et souhaite considérer que leur valeur, dans son ensemble, comme un entier de 32 bits, en utilisant des moyens de types non signés, on peut simplement dire:

  value = byte0 | (byte1*256) | (byte2*65536) | (byte3*16777216);

Par contre, si les octets ont été signés, une expression comme ci-dessus serait plus compliqué.

Je ne sais pas je ne vois vraiment aucune raison pour une langue conçue de nos jours de ne pas inclure des versions non signées de tous les types plus courts que le type entier le plus long signé, avec la sémantique que tout entier (ce qui signifie discret quantité-numerics, plutôt que toutes les opérations de type particulier) qui conviendront tout à fait dans le plus grand type signé sera par défaut effectués comme si ils fonctionnaient sur ce type. Y compris une version non signée du plus grand type signé compliquerait la spécification du langage (car il faudrait préciser quelles opérations doivent correspondre à la portée du type signé, et quelles opérations doivent correspondre à la portée du type non signé), mais sinon il devrait y avoir pas de problème la conception d'une langue afin que if (unsigned1 - unsigned2 > unsigned3) donnerait un résultat « numériquement correcte », même lorsque unsigned2 est supérieure à unsigned1 [si l'on veut non signé wraparound, on préciserait explicitement if ((Uint32)(unsigned1 - unsigned2) > unsigned3)]. Une langue qui spécifiait un tel comportement serait certainement une grande amélioration par rapport à la pagaille qui existe en C (justifiable, compte tenu de son histoire), C # ou vb.net.