En C#, ¿por qué es "int" un alias para System.Int32?
types language-design (2)
Ya que C # es compatible con Int8 , Int16 , Int32 e Int64 , ¿por qué los diseñadores del lenguaje eligieron definir int como un alias para Int32 lugar de permitir que varíe dependiendo de lo que la arquitectura nativa considera una word ?
No he tenido ninguna necesidad específica de que el int comporte de manera diferente a la forma en que lo hace, solo lo pregunto por puro interés enciclopédico.
Pensaría que posiblemente podría existir una arquitectura RISC de 64 bits que admitiría de manera más eficiente solo cantidades de 64 bits, y en la que las manipulaciones de cantidades de 32 bits requerirían operaciones adicionales. Dicha arquitectura estaría en desventaja en un mundo en el que los programas insisten en usar enteros de 32 bits, que es otra forma de decir que C #, convirtiéndose en el lenguaje del futuro y todo, esencialmente evita que los diseñadores de hardware lleguen a tener tales Una arquitectura en el futuro.
StackOverflow no fomenta la especulación de respuestas, así que solo responda si su información proviene de una fuente confiable. Me he dado cuenta de que algunos miembros de SO son miembros de Microsoft, por lo que esperaba poder informarnos sobre este tema.
Nota 1: De hecho, leí todas las respuestas y todos los comentarios de SO: ¿Es seguro asumir que un int siempre tendrá 32 bits en C #? pero no encontré ninguna pista en cuanto al por qué lo estoy preguntando en esta pregunta.
Nota 2: la viabilidad de esta pregunta sobre SO se discute (de manera no concluyente) aquí: Meta: ¿Puedo preguntar el tipo de pregunta "por qué lo hicieron de esta manera"?
Creo que su principal razón fue la portabilidad de los programas dirigidos a CLR. Si tuvieran que permitir que un tipo tan básico como int fuera depender de la plataforma, hacer programas portátiles para CLR sería mucho más difícil. La proliferación de tipos integrales tipográficos en el código C / C ++ de plataforma neutral para cubrir el uso de int incorporado es una sugerencia indirecta de por qué los diseñadores de CLR decidieron hacer que los tipos incorporados sean independientes de la plataforma. Discrepancias como esa son un gran inhibidor del objetivo de "escribir una vez, ejecutar en cualquier lugar" de los sistemas de ejecución basados en máquinas virtuales.
Editar La mayoría de las veces, el tamaño de un int reproduce implícitamente en su código a través de operaciones de bit, en lugar de aritmética (después de todo, ¿qué podría salir mal con el i++ , verdad?) Pero los errores suelen ser más sutiles. Considere un ejemplo a continuación:
const int MaxItem = 20;
var item = new MyItem[MaxItem];
for (int mask = 1 ; mask != (1<<MaxItem) ; mask++) {
var combination = new HashSet<MyItem>();
for (int i = 0 ; i != MaxItem ; i++) {
if ((mask & (1<<i)) != 0) {
combination.Add(item[i]);
}
}
ProcessCombination(combination);
}
Este código calcula y procesa todas las combinaciones de 20 elementos. Como puede ver, el código falla miserablemente en un sistema con int 16 bits, pero funciona bien con ints de 32 o 64 bits.
El código inseguro proporcionaría otra fuente de dolor de cabeza: cuando el int se arregla en algún tamaño (por ejemplo, 32), el código asigna 4 veces el número de bytes que el número de entradas que necesita para calcular que funcionaría, aunque sea técnicamente incorrecto utilizar 4 en lugar de sizeof(int) . Por otra parte, este código técnicamente incorrecto seguirá siendo portátil!
En última instancia, pequeñas cosas como esa juegan un papel importante en la percepción de la plataforma como "buena" o "mala". A los usuarios de los programas .NET no les importa que un programa se bloquee porque su programador cometió un error no portátil, o el CLR tiene errores. Esto es similar a la forma en que los primeros Windows se percibían como no estables debido a la mala calidad de los controladores. Para la mayoría de los usuarios, una falla es solo otra falla del programa .NET, no un problema de los programadores. Por lo tanto, es bueno para la percepción del "ecosistema .NET" para hacer que el estándar sea lo más indulgente posible.
Muchos programadores tienen la tendencia de escribir código para la plataforma que utilizan. Esto incluye suposiciones sobre el tamaño de un tipo. Hay muchos programas de C en torno a los cuales fallará si el tamaño de un int se cambiaría a 16 o 64 bits porque se escribieron bajo el supuesto de que un int es de 32 bits. La elección para C # evita ese problema simplemente definiéndolo como eso. Si define int como variable dependiendo de la plataforma, volverá al mismo problema. Aunque se podría argumentar que es culpa de los programadores hacer suposiciones erróneas, hace que el lenguaje sea un poco más robusto (IMO). Y para las plataformas de escritorio, un int de 32 bits es probablemente la ocurrencia más común. Además, hace que portar el código C nativo a C # sea un poco más fácil.
Edición : creo que escribes código que hace suposiciones (implícitas) sobre el tamaño de un tipo más a menudo de lo que crees. Básicamente, cualquier cosa que implique una serialización (como .NET remoting, WCF, serializar datos en el disco, etc.) le causará problemas si permite tamaños de variables para int, a menos que el programador se encargue de usar el tipo de tamaño específico como int32 . Y luego terminas con "usaremos int32 siempre de todos modos por si acaso" y no has ganado nada.