Dlaczego niepodpisane int nie są zgodne z CLS?


111

Dlaczego liczby całkowite bez znaku nie są zgodne z CLS?

Zaczynam myśleć, że specyfikacja typu służy tylko do wydajności, a nie do poprawności.

Odpowiedzi:


88

Nie wszystkie języki mają koncepcję bez znaku int. Na przykład VB 6 nie miał koncepcji niepodpisanych int, co, jak podejrzewam, wpłynęło na decyzję projektantów VB7 / 7.1, aby również nie wdrażać (jest teraz zaimplementowany w VB8).

Cytować:

http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

CLS został zaprojektowany tak, aby był wystarczająco duży, aby zawierać konstrukcje językowe, które są powszechnie potrzebne programistom, a jednocześnie na tyle mały, że większość języków jest w stanie go obsługiwać. Ponadto każda konstrukcja językowa, która uniemożliwia szybką weryfikację bezpieczeństwa typu kodu, została wykluczona z CLS, tak aby wszystkie języki zgodne z CLS mogły tworzyć weryfikowalny kod, jeśli zdecydują się to zrobić.

Aktualizacja: zastanawiałem się nad tym kilka lat temu i chociaż nie rozumiem, dlaczego UInt nie byłby weryfikowalny pod względem bezpieczeństwa typu, myślę, że faceci z CLS musieli mieć gdzieś punkt odcięcia, co byłoby podstawowym minimum liczba obsługiwanych typów wartości. Również, gdy myślisz o dłuższej perspektywie, w której coraz więcej języków jest przenoszonych do CLR, po co zmuszać je do implementacji unsigned ints, aby uzyskać zgodność z CLS, jeśli nie ma absolutnie żadnej koncepcji, nigdy?


@Kevin: Właśnie zastanawiałem się nad tematem. Twoja odpowiedź wydaje się logiczna. Po prostu lubię myśleć o temacie. Myślę, że szkoda, że ​​typy podobne do Pascala nie dostały się do CLR. Ale twój argument dotyczący innych języków: to nie powstrzymało IronPythona od używania silnie dynamicznego typowania (DLR) w silnie statycznym typie CLR?
doekman

@doekman: Chociaż tak, IronPython i IronRuby demonstrują, że CLR może zapewnić platformę, na której można budować języki dynamicznie wpisywane, celem CLS było zapewnienie zestawu standardów, które wykraczają poza funkcjonalność języka i pozwalają im na pomyślną i bezpieczną współpracę. Nie sądzę, co język może zrobić pod względem dodawania funkcji DL, jest bezpośrednio związane z tym, co powinno znaleźć się w CLS / CTS.
Kev

Z mojego zrozumienia CLR ma jeden 32-bitowy typ pierwotny liczby całkowitej, który ma oddzielne instrukcje dodawania ze znakiem ze sprawdzaniem przepełnienia, dodawanie bez znaku z kontrolą przepełnienia i mod dodawania niezależnego od znaku 2 ^ 32 itd .; gdy zostanie poproszony o konwersję odwołania do obiektu na 32-bitową liczbę całkowitą, CLR nie wie ani nie dba o to, czy kod używający tego numeru oczekuje, że będzie on podpisany, czy nie. To, czy kompilator uważa, że ​​liczba jest podpisana, czy niepodpisana, ogólnie wpłynie na to, jakie instrukcje kompilator generuje dla operacji z nią, ale jest to kwestia języka, a nie CLR.
supercat

23

Podejrzewam, że część problemu obraca się wokół faktu, że typy całkowite bez znaku w C muszą zachowywać się jak elementy abstrakcyjnego pierścienia algebraicznego, a nie jako liczby [co oznacza na przykład, że jeśli 16-bitowa zmienna całkowita bez znaku równa się zero , odliczanie jest wymaganeaby uzyskać 65 535, a jeśli jest równe 65 535, to zwiększanie wartości jest wymagane do uzyskania zera]. Są chwile, kiedy takie zachowanie jest niezwykle przydatne, ale typy liczbowe wykazują takie zachowanie może być sprzeczne z duchem niektórych języków. Przypuszczałbym, że decyzja o pominięciu typów bez znaku prawdopodobnie poprzedza decyzję o obsłudze zarówno sprawdzonych, jak i niesprawdzonych kontekstów numerycznych. Osobiście żałuję, że nie było oddzielnych typów całkowitych dla liczb bez znaku i pierścieni algebraicznych; zastosowanie jednoargumentowego operatora minus do 32-bitowej liczby bez znaku powinno dać wynik 64-bitowy ze znakiem [zanegowanie czegokolwiek innego niż zero dałoby liczbę ujemną], ale zastosowanie jednoargumentowego minus do typu pierścienia powinno dać addytywną odwrotność w tym pierścieniu.

W każdym razie powodem, dla którego liczby całkowite bez znaku nie są zgodne z CLS, jest to, że firma Microsoft zdecydowała, że ​​języki nie muszą obsługiwać liczb całkowitych bez znaku, aby można je było uznać za „zgodne z CLS”.


Doskonałe wyjaśnienie z matematycznej perspektywy!
dizarter

6

Niepodpisane liczby int nie przynoszą zbyt wiele korzyści w prawdziwym życiu, jednak posiadanie więcej niż 1 typu int powoduje ból, więc wiele języków ma tylko pojedyncze int.

Zgodność z CLS ma na celu umożliwienie korzystania z klasy z wielu języków…

Pamiętaj, że nikt nie zmusza Cię do przestrzegania CLS.

Nadal można używać bez znaku int w metodzie lub jako param do metody prywatnej , ponieważ jest to tylko publiczny interfejs API, który ogranicza zgodność z CLS.


16
Są dość istotne, jeśli robisz jakąkolwiek arytmetykę bitową.
nicodemus13

@ nicodemus13 kiedy ostatnio widziałeś system administracyjny firmy, który miał arytmetykę bitową w swojej domenie powodującej problemy? (Np. Rodzaj oprogramowania, które piszą programiści VB.NET)
Ian Ringrose

38
Wszystko, co ma sumę kontrolną, będzie używać arytmetyki bitowej, jest to dość powszechne i wydaje mi się dziwne, aby przeciągać w dół każdy inny język, ponieważ VB nie obsługuje liczb całkowitych bez znaku. NET ma być również generyczne, nie tylko dla autorów VB aplikacji LOB. Kiedy mówisz „1 typ int”, nie uważasz, że posiadanie bajtu, krótkiego, int, długiego również jest uciążliwe? Nie bardzo rozumiem, dlaczego podpisywanie jest bardziej niezręczne.
nicodemus13

5

Liczby całkowite bez znaku nie są zgodne z CLS, ponieważ nie są interoperacyjne między niektórymi językami.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.