¿Es un número entero de 64 bits en C # de 64 bits?

En mi código fuente de C # puedo haber declarado enteros como:

int i = 5; 

o

 Int32 i = 5; 

En el mundo actual de 32 bits, son equivalentes. Sin embargo, a medida que avanzamos hacia un mundo de 64 bits, ¿estoy en lo correcto al decir que lo siguiente se convertirá en lo mismo?

 int i = 5; Int64 i = 5; 

No. La especificación C # define rígidamente que int es un alias para System.Int32 con exactamente 32 bits. Cambiar esto sería un gran cambio radical.

La palabra clave int en C # se define como un alias para el tipo System.Int32 y esto es (a juzgar por el nombre) destinado a ser un entero de 32 bits. Para la especificación:

La sección de especificación CLI 8.2.2 (valor incorporado y tipos de referencia) tiene una tabla con lo siguiente:

  • System.Int32System.Int32 entero de 32 bits con signo

La sección de especificación de C # 8.2.1 (tipos predefinidos) tiene una tabla similar:

  • int – tipo integral con signo de 32 bits

Esto garantiza que tanto System.Int32 en CLR como int en C # siempre serán de 32 bits.

¿Sizeof (testInt) alguna vez será 8?

No, sizeof (testInt) es un error. TestInt es una variable local. El operador sizeof requiere un tipo como argumento. Esto nunca será 8 porque siempre será un error.

VS2010 comstack el entero gestionado ac # como 4 bytes, incluso en una máquina de 64 bits.

Correcto. Observo que la sección 18.5.8 de la especificación C # define sizeof(int) como la constante de tiempo de comstackción 4. Es decir, cuando dices sizeof(int) el comstackdor simplemente reemplaza eso con 4; es como si dijeras “4” en el código fuente.

¿Alguien sabe si / cuándo llegará el momento en que un “int” estándar en C # tendrá 64 bits?

Nunca. La sección 4.1.4 de la especificación C # establece que “int” es un sinónimo de “System.Int32”.

Si lo que quieres es un “entero del tamaño de un puntero”, entonces usa IntPtr. Un IntPtr cambia su tamaño en diferentes architectures.

int es siempre sinónimo de Int32 en todas las plataformas.

Es muy poco probable que Microsoft lo cambie en el futuro, ya que rompería muchos códigos existentes que suponen que int es de 32 bits.

Creo que lo que puede confundirte es que int es un alias para Int32 por lo que siempre será de 4 bytes, pero se supone que IntPtr debe coincidir con el tamaño de palabra de la architecture de la CPU, por lo que será de 4 bytes en un sistema de 32 bits y 8 bytes en un sistema de 64 bits.

De acuerdo con la especificación de C # ECMA-334 , sección “11.1.4 Tipos simples”, la palabra reservada int se alias a System.Int32 . Como esto está en la especificación, es muy poco probable que cambie.

No importa si está utilizando la versión de 32 bits o la versión de 64 bits del CLR, en C # una int siempre significará System.Int32 y long siempre significará System.Int64 .

Lo siguiente siempre será verdadero en C #:

Sbyte firmó 8 bits, 1 byte

byte sin signo de 8 bits, 1 byte

corto firmado 16 bits, 2 bytes

ushort unsigned 16 bits, 2 bytes

int firmado 32 bits, 4 bytes

uint unsigned 32 bits, 4 bytes

largo firmado 64 bits, 8 bytes

ulong unsigned 64 bits, 8 bytes

Un literal entero es solo una secuencia de dígitos (p 314159 Ej., 314159 ) sin ninguno de estos tipos explícitos. C # le asigna el primer tipo en la secuencia ( int , uint , long , ulong ) en la que se ajusta. Esto parece haber sido ligeramente confuso en al menos una de las respuestas anteriores.

Extrañamente, el operador menos unario (signo menos) que aparece antes de una cadena de dígitos no reduce la elección a ( int , largo ). Lo literal siempre es positivo; el signo menos realmente es un operador. Entonces, supuestamente, -314159 es exactamente lo mismo que -((int)314159) . Excepto que aparentemente hay un caso especial para obtener -2147483648 directamente en un int ; de lo contrario, sería -((uint)2147483648) . Lo cual supongo que hace algo desagradable.

De alguna manera, parece seguro predecir que C # (y sus amigos) nunca se molestarán con tipos de “nombre blando” para enteros de> = 128 bits. Obtendremos un buen soporte para enteros arbitrariamente grandes y soporte súper preciso para UInt128, UInt256, etc. tan pronto como los procesadores soporten hacer matemática de esa manera, y casi nunca utilicen nada de eso. Los espacios de direcciones de 64 bits son realmente grandes. Si alguna vez son demasiado pequeños, será por alguna razón esotérica como ASLR o una MapReduce más eficiente o algo así.

Sí, como dijo Jon, y a diferencia del ‘mundo C / C ++’, Java y C # no dependen del sistema en el que se ejecutan. Tienen longitudes estrictamente definidas para byte / short / int / long y flotantes de precisión simple / doble, iguales en cada sistema.

int sin sufijo puede ser de 32 bits o de 64 bits, depende del valor que representa.

como se define en MSDN:

Cuando un literal entero no tiene sufijo, su tipo es el primero de estos tipos en que se puede representar su valor: int, uint, long, ulong.

Aquí está la dirección: https://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx