¿Es un int un entero de 64 bits en C # de 64 bits?

StackOverflow https://stackoverflow.com/questions/164643

  •  03-07-2019
  •  | 
  •  

Pregunta

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

int i = 5;

o 

Int32 i = 5;

En el mundo de 32 bits que prevalece actualmente son equivalentes. Sin embargo, a medida que avanzamos hacia un mundo de 64 bits, ¿estoy en lo cierto al decir que lo siguiente será lo mismo? 

int i = 5;
Int64 i = 5;
¿Fue útil?

Solución

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 major rompiendo el cambio.

Otros consejos

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

  

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

     
      
  • System.Int32 - Entero de 32 bits firmado
    •   
     

especificación de C # sección 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.

  ¿

será sizeof (testInt) alguna vez 8?

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

  

VS2010 compila un entero administrado c # 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 compilación 4. Es decir, cuando dices sizeof (int) la el compilador simplemente reemplaza eso con 4; es como si hubieras dicho " 4 " en el código fuente.

  

¿Alguien sabe si / cuándo llegará el momento en que un estándar " int " en C # serán 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 de tamaño de puntero " luego use IntPtr. Un IntPtr cambia su tamaño en diferentes arquitecturas.

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

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

Creo que lo que te puede confundir es que int es un alias para Int32 , por lo que siempre será de 4 bytes, pero IntPtr se supone que coincide con el tamaño de palabra de la arquitectura 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 tendrá un alias en System.Int32 . Dado que 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 # un int siempre significará System.Int32 y < código> largo siempre significará System.Int64 .

Lo siguiente siempre será verdadero en C #:

sbyte firmado 8 bits, 1 byte

byte sin firmar 8 bits, 1 byte

corto firmado 16 bits, 2 bytes

ushort sin firmar 16 bits, 2 bytes

int firmado 32 bits, 4 bytes

uint 32 bits sin signo, 4 bytes

largo firmado 64 bits, 8 bytes

ulong sin firmar 64 bits, 8 bytes

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

Extrañamente el el operador menos unificado (signo menos) que aparece antes de una cadena de dígitos no reduce la opción a ( int , largo ) . El literal es siempre positivo; el signo menos realmente es un operador. Entonces, presumiblemente, -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) . Que supongo que hace algo desagradable.

De alguna manera, parece seguro predecir que C # (y sus amigos) nunca se molestarán con " nombre de Squishy " tipos para enteros de > = 128 bits. Obtendremos un buen soporte para enteros grandes arbitrariamente y un soporte superpreciso para UInt128, UInt256, etc., tan pronto como los procesadores admitan el cálculo matemático, y casi nunca usamos 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 un 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 flotadores de precisión de byte / short / int / long y single / double, iguales en todos los sistemas.

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

como se define en MSDN:

  

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

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top