Un int est-il un entier 64 bits en C # 64 bits?

Question

Dans mon code source C #, j'ai peut-être déclaré des entiers sous la forme:

int i = 5;

ou

Int32 i = 5;

Dans le monde 32 bits actuel, ils sont équivalents. Cependant, alors que nous entrons dans un monde 64 bits, ai-je raison de dire que ce qui suit va devenir le même?

int i = 5;
Int64 i = 5;

Answer 1

Non. La spécification C # définit rigoureusement que int est un alias pour System.Int32 avec exactement 32 bits. Changer cela constituerait un changement radical majeur .

Answer 2

Le mot clé int en C # est défini comme un alias pour le type System.Int32 et il s'agit (à en juger par le nom) d'un entier 32 bits. . Pour le cahier des charges:

  

Spécification de la CLI section 8.2.2 (Valeur intégrée et types de référence) contient un tableau avec les éléments suivants:

     

  
• System.Int32 - Entier 32 bits signé
  

     

Spécification C # section 8.2.1 (Types prédéfinis) a un tableau similaire:

     

  
• int - type intégral signé 32 bits
  

Cela garantit que System.Int32 dans CLR et int dans C # sera toujours 32 bits.

Answer 3

  

Est-ce que sizeof (testInt) sera 8?

Non, sizeof (testInt) est une erreur. testInt est une variable locale. L'opérateur sizeof nécessite un type comme argument. Ce ne sera jamais 8 parce que ce sera toujours une erreur.

  

VS2010 compile un entier géré c # en tant que 4 octets, même sur un ordinateur 64 bits.

Corrigez. Je remarque que la section 18.5.8 de la spécification C # définit sizeof (int) comme étant la constante de compilation 4. C'est-à-dire, lorsque vous dites sizeof (int) le compilateur remplace simplement cela par 4; c’est comme si vous aviez dit " 4 " dans le code source.

  

Est-ce que quelqu'un sait si / quand le moment viendra qu'un standard "& int;"; en C # sera 64 bits?

Jamais. La section 4.1.4 de la spécification C # indique que " int " est un synonyme de "System.Int32".

Si vous voulez un "nombre entier de la taille d'un pointeur" puis utilisez IntPtr. Un IntPtr change de taille sur différentes architectures.

Answer 4

int est toujours synonyme de Int32 sur toutes les plateformes.

Il est très peu probable que Microsoft modifie cela à l'avenir, car cela briserait beaucoup de code existant qui suppose que int est en 32 bits.

Answer 5

Je pense que vous pouvez être dérouté par le fait que int est un alias pour Int32 , donc ce sera toujours 4 octets, mais IntPtr est supposé correspondre à la taille de mot de l’architecture de la CPU, donc 4 octets sur un système 32 bits et 8 octets sur un système 64 bits.

Answer 6

Conformément à la spécification C #, ECMA-334 , section "11.1.4 Types simples", le mot réservé int sera associé à System.Int32 . Comme cela est dans la spécification, il est très peu probable que cela change.

Answer 7

Que vous utilisiez la version 32 bits ou la version 64 bits du CLR, en C #, un int signifiera toujours System.Int32 et < code> long signifiera toujours System.Int64 .

Answer 8

Le texte suivant sera toujours vrai en C #:

sbyte signé 8 bits, 1 octet

octet 8 bits non signés, 1 octet

court signé 16 bits, 2 octets

ushort 16 bits non signés, 2 octets

int 32 bits signés, 4 octets

uint 32 bits non signés, 4 octets

long signé 64 bits, 8 octets

ulong 64 bits non signés, 8 octets

Un entier littéral est simplement une séquence de chiffres (par exemple, 314159 ) sans aucun de ces types explicites. C # lui attribue le premier type de la séquence ( int , uint , long , ulong ) dans lequel il s'inscrit . Cela semble avoir été légèrement embrouillé dans au moins une des réponses ci-dessus.

Bizarrement , le opérateur unaire moins (le signe moins) qui apparaît avant qu'une chaîne de chiffres ne ne ne réduise pas le choix de ( int , long ) . Le littéral est toujours positif; le signe moins est vraiment un opérateur. Donc, vraisemblablement, -314159 est exactement la même chose que - ((int) 314159) . Sauf qu'apparemment, il existe un cas particulier pour insérer -2147483648 directement dans un int ; sinon ce serait - ((uint) 2147483648) . Je suppose que cela fait quelque chose de désagréable.

D'une manière ou d'une autre, il semble prudent de prédire que C # (et ses amis) ne s'embarrassera jamais de " nom squishy " types pour > = entiers 128 bits. Nous aurons un support intéressant pour arbitrairement de grands entiers et un support ultra-précis pour UInt128, UInt256, etc. dès que les processeurs prendront en charge le traitement mathématique aussi large, et n'en utilisent presque jamais. Les espaces d'adressage 64 bits sont vraiment grands. S'ils sont trop petits, ce sera pour une raison ésotérique comme ASLR ou un MapReduce plus efficace ou autre chose.

Answer 9

Oui, comme l'a dit Jon, et contrairement au "monde C / C ++", Java et C # ne dépendent pas du système sur lequel ils s'exécutent. Ils ont des longueurs strictement définies pour les flottants octet / short / int / long et simple / double précision, identiques sur tous les systèmes.

Answer 10

int sans suffixe peut être 32 bits ou 64 bits, cela dépend de la valeur qu'il représente.

tel que défini dans MSDN:

  

Lorsqu'un littéral entier n'a pas de suffixe, son type est le premier de ces types dans lequel sa valeur peut être représentée: int, uint, long, ulong.

Voici l'adresse: https://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx