В C # почему «int» является псевдонимом для System.Int32?

Question

Поскольку C # поддерживает Int8, Int16, Int32 и Int64, почему разработчики языка решили определить int в качестве псевдонима для Int32 вместо того, чтобы разрешать его варьировать в зависимости отто, что нативная архитектура считает word?

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

Я думаю, что может существовать 64-битная RISC-архитектура, которая наиболее эффективно будет поддерживать только 64-битные величины, и в которой манипуляции с 32-битными величинами потребуют дополнительных операций.Такая архитектура была бы в невыгодном положении в мире, в котором программы настаивают на использовании 32-разрядных целых чисел, что является еще одним способом сказать, что C #, становясь языком будущего и всем остальным, по существу не позволяет разработчикам аппаратного обеспечения когда-либо придумывать такиеархитектура в будущем.

StackOverflow не поощряет спекулятивные ответы, поэтому, отвечайте, только если ваша информация поступает из надежного источника.Я заметил, что некоторые члены SO являются инсайдерами Microsoft, поэтому я надеялся, что они смогут просветить нас по этому вопросу.

_{Примечание 1: Я действительно прочитал все ответы и все комментариииз SO: Можно ли предположить, что int всегда будет 32-битным в C #? , но не нашел никаких подсказок относительно , почему , который я задаю в этом вопросе.}

_{Примечание 2: жизнеспособность этого вопроса на SO (безрезультатно) обсуждается здесь: Meta: Могу я задать вопрос типа «почему они так поступили»?}

Answer 1

Я считаю, что их основной причиной была мобильность программ, ориентированных на CLR.Если бы они допускали, чтобы базовый тип, такой как int, зависел от платформы, создание переносимых программ для CLR стало бы намного сложнее.Распространение целочисленных типов typedef в независимом от платформы коде C / C ++ для использования встроенного int является косвенным указанием на то, почему разработчики CLR решили сделать встроенные типы независимыми от платформы.Подобные несоответствия являются серьезным препятствием для достижения цели: «пиши один раз, беги куда угодно» систем исполнения на основе виртуальных машин.

Edit Чаще всего размер int воспроизведенияв ваш код неявно через битовые операции, а не через арифметику (в конце концов, что может пойти не так с i++, верно?) Но ошибки, как правило, более тонкие.Рассмотрим пример ниже:

const int MaxItem = 20;
var item = new MyItem[MaxItem];
for (int mask = 1 ; mask != (1<<MaxItem) ; mask++) {
    var combination = new HashSet<MyItem>();
    for (int i = 0 ; i != MaxItem ; i++) {
        if ((mask & (1<<i)) != 0) {
            combination.Add(item[i]);
        }
    }
    ProcessCombination(combination);
}

Этот код вычисляет и обрабатывает все комбинации из 20 элементов.Как вы можете сказать, код с треском проваливается в системе с 16-битным int, но отлично работает с 32-битными или 64-битными.

Небезопасный код может стать источником головной боли: когда int исправлен в коде некоторого размера (скажем, 32), который выделяет в 4 раза больше байтов, сколько будет работать нужное ему число, даже если технически некорректно использовать 4 вместо sizeof(int).Более того, этот технически некорректный код останется переносимым!

В конечном счете, такие мелкие вещи сильно влияют на восприятие платформы как «хорошее» или «плохое».Пользователи программ .NET не заботятся о том, что программа аварийно завершает работу, потому что ее программист допустил непереносимую ошибку или CLR содержит ошибки.Это похоже на то, как ранние версии Windows воспринимались как нестабильные из-за низкого качества драйверов.Для большинства пользователей сбой - это просто очередной сбой программы .NET, а не проблема программистов.Следовательно, для восприятия «экосистемы .NET» полезно сделать стандарт как можно более щадящим.

Answer 2

Многие программисты имеют тенденцию писать код для платформы, которую они используют.Это включает в себя предположения о размере типа.Существует много программ на C, которые могут потерпеть неудачу, если размер int будет изменен на 16 или 64-битный, потому что они написаны в предположении, что int 32-битный.Выбор C # позволяет избежать этой проблемы, просто определяя его как таковой.Если вы определяете int как переменную в зависимости от платформы, вы возвращаетесь к той же самой проблеме.Хотя вы можете утверждать, что это ошибка программистов в неправильных предположениях, это делает язык немного более устойчивым (IMO).И для настольных платформ 32-битное int, вероятно, является наиболее распространенным явлением.Кроме того, это немного упрощает перенос собственного кода C на C #.

Edit : Я думаю, вы пишете код, который делает (неявные) предположения о размернике типа чаще, чем вы думаете.В основном все, что включает в себя сериализацию (например, .NET remoting, WCF, сериализацию данных на диск и т. Д.), Доставит вам неприятности, если вы разрешите переменные размера для int, если программист не позаботится об этом, используя тип определенного размера, например int32,И тогда вы получите «мы всегда будем использовать int32 на всякий случай», и вы ничего не получили.