¿Es un int un entero de 64 bits en C # de 64 bits?
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;
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 firmadoespecificació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