tipos - ¿Es un número entero de 64 bits en C#de 64 bits?
tipos de datos en c# pdf (10)
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 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 .
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.
¿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 compila 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 compilación 4. Es decir, cuando dices sizeof(int) el compilador 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 arquitecturas.
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 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 se alias a System.Int32 . Como esto está en la especificación, es muy poco probable que cambie.
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.Int32-System.Int32entero de 32 bits con signoLa 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.
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.
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
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í.