¿Por qué DateTime.Now.Year es int y no ushort

Question

En la estructura DateTime de .Net framework, Year se define como int (que en realidad es A System.Int32). Sin embargo, la documentación de MSDN dice que el valor siempre será between 1 and 9999. Por lo tanto, un ushort (System.UInt16) es más que adecuado para almacenar el valor y ocupa la mitad del espacio. Entonces, ¿por qué es un int y no un ushort?

Hay una conversión implícita de ushort a int, por lo que no es necesario realizar una conversión para hacer una aritmética de enteros en el año.

Me doy cuenta de que esto es un problema de micro-optimización y por lo tanto no es muy importante. Tengo curiosidad.

Answer 1

Por lo tanto, un ushort (System.UInt16) es más que adecuado para almacenar el valor y ocupa la mitad del espacio.

¿Dónde crees que se está desperdiciando "espacio"? DateTime no almacena cada componente en un campo separado de todos modos. Si estás almacenar el año en algún lugar, no dude en echarlo a un ushort - y echó a un Monthbyte, etc.

Tenga en cuenta que ushort no es compatible con CLS, que es probablemente la razón para ello . Hay un lote de propiedades que tendría sentido que no estén firmadas, como string.Length, etc. pero el marco intenta cumplir con CLS donde puede.

unidad

Answer 2

• devuelve un entero sin signo de 16 bits
• Int devuelve un entero de 32 bits.

Supongo que el compilador JIT aprovecha la arquitectura de la CPU y, por lo tanto, el procesamiento a 32 bits sería más eficiente que 16 bits. Creo que hubo un debate similar con VB6 cuando se usa Integers vs Longs (Bytes asignados vs Architecture Speed).

http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/451845.aspx