En C#, pourquoi "int" est-il un alias de System.Int32 ?

Question

Puisque C# supporte Int8 , Int16 , Int32 y Int64 pourquoi les concepteurs de la langue ont choisi de définir int comme un alias pour Int32 au lieu de la laisser varier en fonction de ce que l'architecture native considère comme une word ?

Je n'ai pas eu de besoin spécifique pour int pour se comporter différemment de la façon dont il le fait, je demande seulement par pur intérêt encyclopédique.

Je pense qu'il est concevable qu'une architecture RISC 64 bits puisse exister, qui ne prendrait en charge que les quantités de 64 bits de la manière la plus efficace, et dans laquelle les manipulations de quantités de 32 bits nécessiteraient des opérations supplémentaires. Une telle architecture serait désavantagée dans un monde où les programmes insistent pour utiliser des entiers de 32 bits, ce qui est une autre façon de dire que le C#, en devenant le langage du futur et tout, empêche essentiellement les concepteurs de matériel d'imaginer une telle architecture à l'avenir.

StackOverflow n'encourage pas les réponses spéculatives. Veuillez donc répondre uniquement si vos informations proviennent d'une source fiable. J'ai remarqué que certains membres de SO sont des initiés de Microsoft, j'espérais donc qu'ils pourraient nous éclairer sur ce sujet.

_{Note 1 : J'ai en fait lu toutes les réponses et tous les commentaires de la Commission européenne. <a href="https://stackoverflow.com/questions/164643/is-it-safe-to-assume-an-int-will-always-be-32-bits-in-c">SO : Peut-on supposer qu'un int sera toujours de 32 bits en C# ? </a>mais n'a pas trouvé d'indice quant au <em>pourquoi </em>que je pose dans cette question.}

_{Note 2 : la viabilité de cette question sur le SO est discutée (de manière non concluante) ici : <a href="https://meta.stackexchange.com/questions/117048/can-i-ask-a-why-did-they-do-it-this-way-type-of-question/117061">Méta : Puis-je poser une question du type "pourquoi l'ont-ils fait de cette façon" ?</a>}

Answer 1

Je crois que leur principale raison était la portabilité des programmes ciblant CLR. S'ils devaient autoriser un type aussi basique que int soit dépendant de la plate-forme, la création de programmes portables pour CLR deviendrait beaucoup plus difficile. La prolifération des typedef -dans du code C/C++ neutre par rapport à la plate-forme pour couvrir l'utilisation des types intégraux intégrés. int est une indication indirecte de la raison pour laquelle les concepteurs du CLR ont décidé de rendre les types intégrés indépendants de la plate-forme. Des divergences de ce type constituent un obstacle majeur à l'objectif "écrire une fois, exécuter n'importe où" des systèmes d'exécution basés sur les VM.

Modifier Le plus souvent, la taille d'un int joue dans votre code de manière implicite par le biais d'opérations sur les bits, plutôt que par le biais de l'arithmétique (après tout, qu'est-ce qui pourrait bien se passer avec l'option i++ n'est-ce pas ?) Mais les erreurs sont généralement plus subtiles. Prenons l'exemple suivant :

const int MaxItem = 20;
var item = new MyItem[MaxItem];
for (int mask = 1 ; mask != (1<<MaxItem) ; mask++) {
    var combination = new HashSet<MyItem>();
    for (int i = 0 ; i != MaxItem ; i++) {
        if ((mask & (1<<i)) != 0) {
            combination.Add(item[i]);
        }
    }
    ProcessCombination(combination);
}

Ce code calcule et traite toutes les combinaisons de 20 éléments. Comme vous pouvez le constater, ce code échoue lamentablement sur un système avec des processeurs 16 bits. int mais fonctionne bien avec des ints de 32 ou 64 bits.

Un code non sécurisé fournirait une autre source de maux de tête : lorsque le int est fixé à une certaine taille (disons 32), le code qui alloue 4 fois le nombre d'octets correspondant au nombre d'ints qu'il doit transporter fonctionnerait, même s'il est techniquement incorrect d'utiliser 4 au lieu de sizeof(int) . De plus, ce code techniquement incorrect resterait portable !

En fin de compte, ce genre de petites choses joue un rôle important dans la perception de la plate-forme comme étant "bonne" ou "mauvaise". Les utilisateurs de programmes .NET ne se soucient pas du fait qu'un programme plante parce que son programmeur a commis une erreur non portable, ou que le CLR est bogué. Cela ressemble à la façon dont les premiers Windows étaient largement perçus comme non stables en raison de la mauvaise qualité des pilotes. Pour la plupart des utilisateurs, un plantage n'est qu'un autre plantage de programme .NET, et non un problème de programmeur. Il est donc bon, pour la perception de l'"écosystème .NET", que la norme soit aussi indulgente que possible.

Answer 2

De nombreux programmeurs ont tendance à écrire du code pour la plate-forme qu'ils utilisent. Cela inclut des hypothèses sur la taille d'un type. Il existe de nombreux programmes C qui échoueront si la taille d'un int est modifiée en 16 ou 64 bits, car ils ont été écrits en supposant qu'un int est de 32 bits. Le choix du C# évite ce problème en le définissant simplement comme tel. Si vous définissez int comme variable en fonction de la plate-forme, vous retombez sur le même problème. Bien que l'on puisse dire que c'est la faute des programmeurs qui font de mauvaises suppositions, cela rend le langage un peu plus robuste (IMO). Et pour les plateformes de bureau, un int 32 bits est probablement le cas le plus courant. En outre, cela rend le portage du code C natif vers C# un peu plus facile.

Modifier : Je pense que vous écrivez du code qui fait des hypothèses (implicites) sur le sizer d'un type plus souvent que vous ne le pensez. Fondamentalement, tout ce qui implique la sérialisation (comme le remoting .NET, WCF, la sérialisation des données sur disque, etc.) vous causera des problèmes si vous autorisez des tailles variables pour int, à moins que le programmeur n'y prenne garde en utilisant un type de taille spécifique, comme par exemple int32 . Et puis vous vous retrouvez avec "nous utiliserons toujours int32 de toute façon, juste au cas où" et vous n'avez rien gagné.