Защо unsigned int не са съвместими с CLS?

Защо целите числа без знак не са съвместими с CLS?

Започвам да мисля, че спецификацията на типа е само за производителност, а не за коректност.


person doekman    schedule 08.08.2008    source източник


Отговори (4)


Не всички езици имат концепцията за 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 съответствие, ако няма абсолютно никаква концепция?

person Kev    schedule 08.08.2008
comment
@Kevin: Просто се чудех за темата. Отговорът ти изглежда логичен. Просто обичам да мисля по темата. Мисля, че е жалко, че типовете, подобни на Pascal, не са попаднали в CLR. Но вашият аргумент за други езици: това не спря IronPython да използва силно динамично въвеждане (DLR) в силно статично въведен CLR? - person doekman; 09.08.2008
comment
@doekman: Докато да, IronPython и IronRuby демонстрират, че CLR може да осигури платформа, върху която можете да изградите динамично въведени езици, целта на CLS беше да предостави набор от стандарти, които надхвърлят функционалността на езика и им позволяват да взаимодействат успешно и безопасно. Не мисля, че това, което един език може да направи по отношение на добавянето на DL функции, е пряко свързано с това, което трябва да влезе в CLS/CTS. - person Kev; 09.08.2008
comment
Доколкото разбирам, CLR има един 32-битов целочислен примитивен тип, който има отделни инструкции за подписано добавяне с проверка на препълване, неподписано добавяне с проверка на препълване и знаково агностично добавяне mod 2^32 и т.н.; когато бъде помолен да преобразува препратка към обект в 32-битов примитив с цяло число, CLR нито знае, нито се интересува дали кодът, използващ това число, очаква то да бъде подписано или неподписано. Дали компилаторът вярва, че дадено число е подписано или неподписано, обикновено ще повлияе какви инструкции генерира компилаторът за операции с него, но това е проблем на езика, а не на CLR. - person supercat; 22.01.2015

Подозирам, че част от проблема се върти около факта, че типовете цели числа без знак в C трябва да се държат като членове на абстрактен алгебричен пръстен, а не като числа [което означава например, че ако 16-битова цяло число без знак е равна на нула , намаляването му е необходимо за получаване на 65 535, а ако е равно на 65 535, тогава увеличаването му е необходимо за получаване на нула.] Има моменти, когато подобно поведение е изключително полезно, но числовите типове проявяват такова поведение може да имат противоречи на духа на някои езици. Бих предположил, че решението да се пропуснат неподписани типове вероятно предшества решението да се поддържат както проверени, така и непроверени числови контексти. Лично аз бих искал да има отделни цели числа за числа без знак и алгебрични пръстени; прилагането на унарен минус оператор към 32-битово число без знак трябва да доведе до 64-битов резултат със знак [отрицанието на нещо различно от нула би довело до отрицателно число], но прилагането на унарен минус към тип пръстен трябва да доведе до адитивната инверсия в този пръстен.

Във всеки случай, причината целите числа без знак да не са съвместими с CLS е, че Microsoft реши, че езиците не трябва да поддържат цели числа без знак, за да се считат за „съвместими с CLS“.

person supercat    schedule 01.06.2014
comment
Отлично обяснение от математическа гледна точка! - person dizarter; 18.06.2015

Неподписаните цели числа не са съвместими с CLS, защото не са оперативно съвместими между определени езици.

person Bryan Roth    schedule 08.08.2008

Unsigned int не ви печелят толкова много в реалния живот, но наличието на повече от 1 тип int ви причинява болка, така че много езици имат само singed int.

CLS съвместимостта има за цел да позволи използването на клас от много езици...

Не забравяйте, че никой не ви кара да спазвате CLS.

Все още можете да използвате неподписани int в метод или като параметри към частен метод, тъй като CLS съвместимият ограничава само публичния API.

person Ian Ringrose    schedule 07.09.2010
comment
Те са доста важни, ако правите някаква битова аритметика. - person nicodemus13; 23.05.2012
comment
@nicodemus13 кога за последен път видяхте система за бизнес администриране, която имаше побитова аритметика в своя проблемен домейн? (Например вида софтуер, който програмистите на VB.NET пишат) - person Ian Ringrose; 24.05.2012
comment
Всичко с контролна сума ще използва побитова аритметика, това е доста обичайно и ми се струва странно да плъзгам всеки друг език надолу, защото VB не поддържа цели числа без знак. .NET също е предназначен да бъде общ, а не само за VB-писатели на LOB приложения. Когато казвате „1 тип int“, не мислите ли, че наличието на byte, short, int, long също е проблем? Не виждам защо подписването е по-неудобно. - person nicodemus13; 24.05.2012