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.
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?
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”.
źródło
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.
źródło
Liczby całkowite bez znaku nie są zgodne z CLS, ponieważ nie są interoperacyjne między niektórymi językami.
źródło