Защо целите числа без знак не са съвместими с CLS?
Започвам да мисля, че спецификацията на типа е само за производителност, а не за коректност.
Защо целите числа без знак не са съвместими с CLS?
Започвам да мисля, че спецификацията на типа е само за производителност, а не за коректност.
Не всички езици имат концепцията за unsigned int. Например VB 6 нямаше концепция за неподписани int, което подозирам, че е довело до решението на дизайнерите на VB7/7.1 също да не се прилагат (сега е внедрено във VB8).
Да цитираш:
http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx
CLS е проектиран да бъде достатъчно голям, за да включва езиковите конструкции, които обикновено са необходими на разработчиците, но достатъчно малък, че повечето езици да могат да го поддържат. В допълнение, всяка езикова конструкция, която прави невъзможно бързата проверка на безопасността на типа на кода, беше изключена от CLS, така че всички CLS-съвместими езици да могат да произвеждат проверяем код, ако решат да го направят.
Актуализация: Чудех се за това преди няколко години и въпреки че не мога да разбера защо UInt няма да може да се провери безопасността на типа, предполагам, че момчетата от CLS трябваше да имат точка на прекъсване някъде за това какъв би бил базовият минимум брой поддържани типове стойности. Също така, когато мислите за по-дългосрочен план, когато все повече и повече езици се пренасят към CLR, защо да ги принуждавате да прилагат неподписани int, за да постигнат CLS съответствие, ако няма абсолютно никаква концепция?
Подозирам, че част от проблема се върти около факта, че типовете цели числа без знак в C трябва да се държат като членове на абстрактен алгебричен пръстен, а не като числа [което означава например, че ако 16-битова цяло число без знак е равна на нула , намаляването му е необходимо за получаване на 65 535, а ако е равно на 65 535, тогава увеличаването му е необходимо за получаване на нула.] Има моменти, когато подобно поведение е изключително полезно, но числовите типове проявяват такова поведение може да имат противоречи на духа на някои езици. Бих предположил, че решението да се пропуснат неподписани типове вероятно предшества решението да се поддържат както проверени, така и непроверени числови контексти. Лично аз бих искал да има отделни цели числа за числа без знак и алгебрични пръстени; прилагането на унарен минус оператор към 32-битово число без знак трябва да доведе до 64-битов резултат със знак [отрицанието на нещо различно от нула би довело до отрицателно число], но прилагането на унарен минус към тип пръстен трябва да доведе до адитивната инверсия в този пръстен.
Във всеки случай, причината целите числа без знак да не са съвместими с CLS е, че Microsoft реши, че езиците не трябва да поддържат цели числа без знак, за да се считат за „съвместими с CLS“.
Неподписаните цели числа не са съвместими с CLS, защото не са оперативно съвместими между определени езици.
Unsigned int не ви печелят толкова много в реалния живот, но наличието на повече от 1 тип int ви причинява болка, така че много езици имат само singed int.
CLS съвместимостта има за цел да позволи използването на клас от много езици...
Не забравяйте, че никой не ви кара да спазвате CLS.
Все още можете да използвате неподписани int в метод или като параметри към частен метод, тъй като CLS съвместимият ограничава само публичния API.