Почему unsigned int несовместимы с CLS?

111

Почему целые числа без знака несовместимы с CLS?

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

докман
источник

Ответы:

88

Не все языки имеют понятие целых чисел без знака. Например, в VB 6 не было концепции беззнаковых целых чисел, что, как я подозреваю, привело к решению разработчиков VB7 / 7.1 не реализовывать его (теперь это реализовано в VB8).

Цитировать:

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

CLS был разработан, чтобы быть достаточно большим, чтобы включать языковые конструкции, которые обычно необходимы разработчикам, но достаточно маленьким, чтобы большинство языков могло его поддерживать. Кроме того, любая языковая конструкция, которая делает невозможным быструю проверку типовой безопасности кода, была исключена из CLS, чтобы все CLS-совместимые языки могли создавать проверяемый код, если они захотят это сделать.

Обновление: я действительно задавался вопросом об этом несколько лет назад, и хотя я не могу понять, почему UInt не может быть проверен на безопасность типов, я думаю, что ребятам из CLS нужно было где-то отрезать точку в отношении того, что будет базовым минимумом количество поддерживаемых типов значений. Кроме того, когда вы думаете о более долгосрочной перспективе, когда все больше и больше языков переносятся в CLR, зачем заставлять их реализовывать беззнаковые целые числа, чтобы добиться соответствия CLS, если вообще нет никакой концепции?

Кев
источник
@Kevin: Я просто подумал об этой теме. Ваш ответ кажется логичным. Мне просто нравится обдумывать эту тему. Мне жаль, что типы, подобные Паскалю, не попали в CLR. Но ваш аргумент о других языках: это не остановило IronPython, использующего строго динамическую типизацию (DLR) в CLR со строго статической типизацией?
doekman
@doekman: Хотя да, IronPython и IronRuby демонстрируют, что CLR может предоставить платформу, на которой вы можете создавать языки с динамической типизацией, целью CLS было предоставить набор стандартов, которые выходят за рамки языковой функциональности и позволяют им успешно и безопасно взаимодействовать. Я не думаю, что то, что может сделать язык с точки зрения добавления функций DL, напрямую связано с тем, что должно входить в CLS / CTS.
Кев
Насколько я понимаю, в CLR есть один 32-битный целочисленный примитивный тип, который имеет отдельные инструкции для добавления со знаком с проверкой переполнения, сложения без знака с проверкой переполнения и беззнакового сложения по модулю 2 ^ 32 и т. Д .; когда его просят преобразовать ссылку на объект в 32-битный целочисленный примитив, среда CLR не знает и не заботится о том, ожидает ли код, использующий это число, знаковое или беззнаковое. Независимо от того, считает ли компилятор число подписанным или неподписанным, обычно влияет на то, какие инструкции компилятор генерирует для операций с ним, но это проблема языка, а не среды CLR.
supercat
23

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

В любом случае причина, по которой целые числа без знака не совместимы с CLS, заключается в том, что Microsoft решила, что языки не должны поддерживать целые числа без знака, чтобы считаться «совместимыми с CLS».

Supercat
источник
Отличное объяснение с математической точки зрения!
dizarter
6

Беззнаковые целые числа в реальной жизни не принесут вам особой пользы, однако наличие более одного типа целых чисел причиняет вам боль, поэтому во многих языках используются только целые числа.

Совместимость с CLS нацелена на то, чтобы позволить использовать класс из множества языков ...

Помните, что никто не заставляет вас соответствовать требованиям CLS.

Вы по-прежнему можете использовать целые числа без знака в методе или как параметры частного метода, поскольку CLS-совместимый ограничивает только общедоступный API.

Ян Рингроуз
источник
16
Они очень важны, если вы занимаетесь побитовой арифметикой.
nicodemus13
@ nicodemus13 когда вы в последний раз видели систему бизнес-администрирования, в проблемной области которой использовалась поразрядная арифметика? (Например, программное обеспечение, которое пишут программисты VB.NET)
Ян Рингроуз,
38
Все, что имеет контрольную сумму, будет использовать поразрядную арифметику, что довольно часто, и мне кажется странным перетаскивать все остальные языки вниз, потому что VB не поддерживает целые числа без знака. .NET также должен быть универсальным, а не только для VB-писателей LOB-приложений. Когда вы говорите «1 тип int», вы не думаете, что наличие byte, short, int, long также является проблемой? Я не совсем понимаю, почему подписывать еще неудобнее.
nicodemus13
5

Целые числа без знака несовместимы с CLS, потому что они не совместимы между определенными языками.

Брайан Рот
источник