В С#, почему "int" является псевдонимом для System.Int32?

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

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

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

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

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

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

Ответ 1

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

Изменить. Чаще всего размер 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 раза больше байтов, так как количество int, которое ему требуется для маршала, будет работать, даже хотя технически некорректно использовать 4 вместо sizeof(int). Более того, этот технически неправильный код останется портативным!

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

Ответ 2

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

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