Dlaczego DateTime.Now.Year int i nie ushort

Question

W strukturze .Net Framework DateTime, Rok jest zdefiniowany jako int (który jest naprawdę A System.Int32). Jednak dokumentacja MSDN mówi, że wartością będzie zawsze between 1 and 9999. Tak więc, ushort (System.UInt16) jest więcej niż wystarczający do przechowywania wartości i zajmuje połowę miejsca. Dlaczego więc jest to int, a nie ushort?

Istnieje niejawne przekształcenie z ushort na int, więc nie ma potrzeby wykonywania rzutów, aby wykonać arytmetykę liczb całkowitych w danym roku.

Zdaję sobie sprawę, że jest to problem dotyczący mikrooptymalizacji, a zatem nie jest bardzo ważny. Jestem po prostu ciekaw.

Answer 1

Tak więc, ushort (System.UInt16) jest więcej niż wystarczający do przechowywania wartości i zajmuje połowę miejsca.

Jak myślisz, gdzie "marnuje się" przestrzeń? DateTime nie zapisuje każdego komponentu w osobnym polu. Jeśli jesteś przechowywania rok gdzieś, nie krępuj się rzucić go do ushort - i oddać Month do byte itp

Zauważ, że nie jest zgodny ushort CLS, który jest prawdopodobnie powód . Istnieje część właściwości, które miałyby sens, aby były niepodpisane, takie jak string.Length itd., Ale struktura próbuje być zgodna z CLS tam, gdzie może.

Answer 2

• urządzenie zwraca komunikat unsigned 16-bitową liczbę całkowitą
• Int Zwraca się 32-bitową liczbę całkowitą.

Zakładam, że kompilator JIT wykorzystuje architekturę procesora i dlatego przetwarzanie na poziomie 32-bitowym byłoby bardziej wydajne niż 16-bitowe. Uważam, że była podobna debata z VB6, gdy używano Integers vs Longs (Bytes allocated vs Architecture Speed).

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