¿Por qué DateTime.Month es un int?

En C #, la DateTimepropiedad Monthtiene un tipo de int(un entero con signo de 32 bits) pero su rango solo será 1-12. ¿Cuáles son las razones por las que el equipo de C # eligió intun tipo numérico más pequeño como byte(entero sin signo de 8 bits)?

c# memory

— Frayt
fuente

A menos que alguien del equipo de diseño de C # esté al acecho, no estoy seguro de que obtendrá una respuesta a esto ...

— Liath

@Liath, eso no ayudará. Me temo. ¿Se puede preguntar "por qué" en las especificaciones del lenguaje como "basado en la opinión primaria" si puede tener respuestas oficiales? (por cierto, una explicación del diseñador de lenguaje C #)

— mosquito

Por cierto, DateTimecomo se implementa en CoreFX, codifica el tiempo como un único valor de 64 bits. La información como días o meses se extrae de ese valor a través de algunas matemáticas inteligentes ( GetDatePart()). Esta no es una razón para usar un int como valor de retorno, simplemente no tiene inconvenientes . Tenga en cuenta también que debido a problemas de alineación, devolver un byte de una función no será más eficiente que devolver un int.

— amon

Estaría tentado a preguntar por qué no se llama un tipo Month.

— bdsl

Lo más probable es que las operaciones realizadas internamente requirieron un int, y los diseñadores del compilador decidieron que no vale la pena convertirlo en otra cosa, probablemente por razones de rendimiento.

— NoChance

Respuestas:

intse usa para casi todas las variables enteras en .NET, aunque a menudo un tipo más pequeño sería suficiente. Además, los tipos sin signo casi nunca se usan, aunque podrían serlo.

Algunos motivos:

Los tipos con signo y sin signo, así como los tipos enteros de diferente tamaño pueden ser incómodos al combinarlos ( +o <por ejemplo). Las reglas no son obvias. Soy un desarrollador experimentado y no podría decirte el conjunto completo de reglas. No necesito saberlo
intes rápido en todas las arquitecturas comunes. Los tipos más pequeños a menudo resultan en conversiones que pueden ser más lentas.
El rendimiento no es un problema para el 99% del código típico. No hay necesidad de pensar demasiado en esto. Solo úsalo en inttodas partes.
La legibilidad es muy buena porque la intención es clara. A bytesugeriría datos binarios, por ejemplo. (Ver comentario de Flater.)

Es una convención útil de usar int.

— usr
fuente

Gracias, estas son algunas buenas razones. Nunca pensé en la implicación de rendimiento de convertir de pequeño a grande o sin firmar a firmado, ya que todo eso está implícito en el código.

— Frayt

Sí, en realidad hice el código más lento una vez usando bytes en lugar de ints, solo use ints; +)

— Joel Harkes

Otro factor podría ser que "todo el mundo prefiere int por defecto" y los diseñadores no querían sorpresas de desajuste de tipo.

— SD

Además de una respuesta completa, la legibilidad es otra razón para usar int. Si vi una bytepropiedad, no pensaría automáticamente que es un valor numérico. Un byte puede ser muchas cosas (por ejemplo, una colección compacta de booleanos). Empujado un poco más, dudo que alguien mire a byte[]y piense "ajá, eso debe ser optimizado List<int>".

— Flater

El punto 3 contradice el punto 2 en esta respuesta. Probablemente una mejor "punto 3" sería "Para el 99% de deducción típica, la sobrecarga de la memoria de 'meses como int' vs 'meses como bytes' no es un problema.

— Doc Brown

Un mes no es un valor. Un mes es solo un mes.

El mapeo 1-12 (que debería haber sido 0-11 imo) solo se hace para que sea más fácil hacer matemáticas con él.

Y una vez que empiezas a hacer cálculos matemáticos, debes ser pragmático. Ints es el valor predeterminado de facto para la matemática entera. Así que usa esos.

Es lo que los programadores esperan. Sin contexto: esperar un int.

Debido a que no le interesa saber si enero es el 1 (o el 0), le interesan las respuestas a preguntas como: "cuántas cuotas mensuales hasta que pagué esta deuda". Y luego descubres que deberías haber usado el entero en lugar del byte.

— Pieter B
fuente