Должен ли я использовать Int или Int32

Question

В C# int а также Int32 это то же самое, но я прочитал несколько раз, что int предпочтительнее Int32 без объяснения причин. Есть ли причина, и я должен заботиться?

Answer 1

ECMA-334: 2006 C# Language Specification (p18):

Каждый из предопределенных типов является сокращением для системного типа. Например, ключевое слово int относится к структуре System.Int32, В качестве стиля использование ключевого слова предпочтительнее, чем использование полного имени типа системы.

Answer 2

Два действительно являются синонимами; int будет немного более знакомым, Int32 делает 32-битность более явной для тех, кто читает ваш код. Я был бы склонен использовать int где мне просто нужно "целое число", Int32 где важен размер (криптографический код, структуры), поэтому будущие сопровождающие будут знать, что безопасно увеличить int если уместно, но следует позаботиться об изменении Int32с таким же образом.

Результирующий код будет идентичен: разница только в удобочитаемости или внешнем виде кода.

Answer 3

Они оба объявляют 32-битные целые числа, и, как утверждали другие авторы, какой из них вы используете, в основном это вопрос синтаксического стиля. Однако они не всегда ведут себя одинаково. Например, компилятор C# не допустит этого:

public enum MyEnum : Int32
{
    member1 = 0
}

но это позволит:

public enum MyEnum : int
{
    member1 = 0
}

Пойди разберись.

Answer 4

Я всегда использую системные типы - например, Int32 вместо int. Я применил эту практику после прочтения Прикладного программирования на.NET Framework - автор Джеффри Рихтер хорошо обосновывает использование полных имен типов. Вот две вещи, которые застряли со мной:

1. Имена типов могут отличаться в разных языках.NET. Например, в C#, long сопоставляется с System.Int64 в C++ с управляемыми расширениями, long сопоставляется с Int32. Поскольку языки могут смешиваться и сочетаться при использовании.NET, вы можете быть уверены, что использование явного имени класса всегда будет более понятным, независимо от предпочтительного языка читателя.

2. Многие методы каркаса имеют имена типов как часть своих имен методов:

   BinaryReader br = new BinaryReader( /* ... */ );

   float val = br.ReadSingle(); // OK, but it looks a little odd...

   Single val = br.ReadSingle(); // OK, and is easier to read

Answer 5

int является ключевым словом C# и является однозначным.

Большую часть времени это не имеет значения, кроме двух вещей, которые идут против Int32:

• Вы должны иметь "использование системы"; заявление. использование "int" не требует использования оператора.
• Можно определить свой собственный класс с именем Int32 (который был бы глупым и запутанным). int всегда означает int.

Answer 6

Как уже говорилось, int знак равно Int32, Чтобы быть в безопасности, обязательно всегда используйте int.MinValue/int.MaxValue при реализации всего, что заботится о границах типов данных. Предположим, что.NET решил, что int теперь будет Int64Ваш код будет меньше зависеть от границ.

Answer 7

Размер байта для типов не слишком интересен, когда вам приходится иметь дело только с одним языком (и для кода, который вам не нужно напоминать себе о математических переполнениях). Интересной становится часть, когда вы соединяете один язык с другим, C# с COM-объектом и т. Д., Или вы выполняете какое-то переключение битов или маскирование, и вам нужно напомнить себе (и вашим коллегам по пересмотру кода) размера данных.

На практике я обычно использую Int32 только для того, чтобы напомнить себе, какого они размера, потому что я пишу управляемый C++ (например, для соединения с C#), а также неуправляемый / нативный C++.

Как вы, наверное, знаете, в C# он 64-битный, но в нативном C++ он заканчивается как 32-битный, или char является unicode/16-битным, тогда как в C++ он 8-битный. Но откуда мы это знаем? Ответ таков, потому что мы посмотрели его в руководстве и сказали, что так.

Со временем и опытом вы начнете быть более добросовестным, когда будете писать коды для связи между C# и другими языками (некоторые читатели здесь думают: "Почему бы вам?"), Но, по-моему, это лучшая практика, потому что Я не могу вспомнить, что я кодировал на прошлой неделе (или мне не нужно указывать в своем документе API, что "этот параметр является 32-разрядным целым числом").

В F# (хотя я никогда не использовал его) они определяют int, int32 и nativeint. Тот же самый вопрос должен подняться: "Какой я использую?". Как уже упоминали другие, в большинстве случаев это не должно иметь значения (должно быть прозрачным). Но я бы, например, выбрал int32 и uint32, чтобы убрать неясности.

Я полагаю, что это будет зависеть от того, какие приложения вы кодируете, кто его использует, какие практики кодирования вы и ваша команда используете, и т. Д., Чтобы обосновать, когда использовать Int32.

Answer 8

Там нет никакой разницы между int а также Int32, но, как int является ключевым словом языка, многие люди предпочитают его стилистически (так же, как и с string против String).

Answer 9

Я всегда использую псевдонимы типа (int, string и т. Д.) При определении переменной и реальное имя при доступе к статическому методу:

int x, y;
...
String.Format ("{0}x{1}", x, y);

Просто кажется уродливым видеть что-то вроде int.TryParse(). Нет другой причины, по которой я делаю это, кроме стиля.

Answer 10

По моему опыту это было условностью. Я не знаю ни одной технической причины использовать int поверх Int32, но это:

1. Быстрее печатать.
2. Более знакомый типичному разработчику C#.
3. Другой цвет в подсветке синтаксиса Visual Studio по умолчанию.

Я особенно люблю этот последний.:)

Answer 11

Хотя они (в основном) идентичны (см. Ниже разницу между [ошибками]), вам определенно следует позаботиться и использовать Int32.

• Имя для 16-разрядного целого числа - Int16. Для 64-разрядного целого числа это Int64, а для 32-разрядного целого числа интуитивно понятный выбор: int или Int32?

• Вопрос о размере переменной типа Int16, Int32 или Int64 является самостоятельным, но вопрос о размере переменной типа int является вполне обоснованным вопросом, и вопросы, какими бы тривиальными они ни были, отвлекают, приводят путанице, тратить время, мешать обсуждению и т. д. (факт, что этот вопрос существует, подтверждает это).

• Использование Int32 способствует тому, что разработчик осознает свой выбор типа. Насколько большой снова Int? Ах да, 32. Вероятность того, что размер шрифта будет фактически учтен, больше, когда размер включен в имя. Использование Int32 также способствует знанию других вариантов. Когда люди не вынуждены хотя бы признавать, что есть альтернативы, для int становится слишком легко стать "целочисленным типом".

• Класс в рамках, предназначенный для взаимодействия с 32-разрядными целыми числами, называется Int32. Еще раз: более интуитивно понятный, менее запутанный, отсутствует (ненужный) перевод (не перевод в системе, а в сознании разработчика) и т. Д. int lMax = Int32.MaxValue или же Int32 lMax = Int32.MaxValue?

• int не является ключевым словом во всех языках.NET.

• Хотя есть аргументы, почему он вряд ли когда-либо изменится, int не всегда может быть Int32.

Недостатками являются два дополнительных символа для ввода и [ошибка].

Это не скомпилируется

public enum MyEnum : Int32
{
    AEnum = 0
}

Но это будет:

public enum MyEnum : int
{
    AEnum = 0
}

Answer 12

Я знаю, что лучше всего использовать int, а весь код MSDN использует int. Однако нет никаких причин, кроме стандартизации и последовательности, насколько я знаю.

Answer 13

Тебя это не должно волновать. Вы должны использовать int большую часть времени. Это поможет в будущем перенести вашу программу на более широкую архитектуру (в настоящее время int псевдоним System.Int32 но это может измениться). Только когда битовая ширина переменной имеет значение (например, для управления макетом в памяти struct) вы должны использовать int32 и другие (со связаннымиusing System;").

Answer 14

Я бы порекомендовал использовать StyleCop от Microsoft.

Это как FxCop, но для вопросов, связанных со стилем. Конфигурация по умолчанию соответствует внутренним руководствам по стилю Microsoft, но ее можно настроить для вашего проекта.

Это может занять некоторое время, чтобы привыкнуть, но это определенно делает ваш код приятнее.

Вы можете включить его в процесс сборки, чтобы автоматически проверять наличие нарушений.

Answer 15

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

Тем не менее, мы, к счастью, больше не видим 16-битную версию, и когда 64-битная версия стала популярной, люди стали больше заботиться о том, чтобы сделать ее совместимой со старым программным обеспечением, а 32-битная была так долго, что для большинства компиляторов int просто предполагается, что это 32 бита.

Answer 16

int такой же, как System.Int32, и при компиляции он превращается в то же самое в CIL.

Мы используем int по соглашению в C#, так как C# хочет выглядеть как C и C++ (и Java), и это то, что мы используем там...

Кстати, я в конечном итоге использую System.Int32 при объявлении импорта различных функций Windows API. Я не уверен, является ли это определенным соглашением или нет, но это напоминает мне, что я иду на внешнюю DLL...

Answer 17

int является ярлыком языка C# для System.Int32

Хотя это действительно означает, что Microsoft может изменить это отображение, в посте обсуждений FogCreek говорится [источник]

"Что касается 64-битной проблемы - Microsoft действительно работает над 64-битной версией.NET Framework, но я уверен, что int НЕ будет отображаться на 64-битную в этой системе.

Причины:

1. Стандарт C# ECMA, в частности, гласит, что int 32-битный, а long 64-битный.

2. Microsoft ввела дополнительные свойства и методы в Framework версии 1.1, которые возвращают длинные значения вместо значений int, такие как Array.GetLongLength в дополнение к Array.GetLength.

Поэтому я думаю, что можно с уверенностью сказать, что все встроенные типы C# сохранят свое текущее отображение ".

Answer 18

На практике это не имеет значения, и со временем вы примете собственное соглашение. Я склонен использовать ключевое слово при назначении типа и версию класса при использовании статических методов и тому подобное:

int total = Int32.Parse ("1009");

Answer 19

int а также Int32 та же. int это псевдоним для Int32,

Answer 20

Вы не должны заботиться. Если размер имеет значение, я бы использовал byte, short, int, затем long. Единственная причина, по которой вы используете int больше, чем int32, это если вам нужно число больше 2147483647 или меньше -2147483648.

Помимо этого мне было бы все равно, есть много других вопросов, которые могут быть обеспокоены.

Answer 21

Я использую int в том случае, если Microsoft изменяет реализацию по умолчанию для целого числа на какую-то новую версию с ошибками (назовем это Int32b).

Затем Microsoft может изменить псевдоним int на Int32b, и мне не нужно менять какой-либо мой код, чтобы воспользоваться их новой (и, надеюсь, улучшенной) целочисленной реализацией.

То же самое касается любого из ключевых слов типа.

Answer 22

int это псевдоним для System.Int32, как определено в этой таблице: Таблица встроенных типов (C# Reference)

Answer 23

Это не важно int - это ключевое слово языка, а Int32 - фактический тип системы.

Смотрите также мой ответ здесь на связанный вопрос.

Answer 24

Вы не должны заботиться о большинстве языков программирования, если только вам не нужно писать очень конкретные математические функции или код, оптимизированный для одной конкретной архитектуры... Просто убедитесь, что вам достаточно размера типа (используйте что-то большее, чем Int, если вы знаю, что вам нужно более 32-битных, например)

Answer 25

С использованием Int32 Для типа требуется ссылка на пространство имен Systemили полностью соответствует (System.Int32). Я склоняюсь к intпотому что он не требует импорта пространства имен, поэтому в некоторых случаях уменьшается вероятность конфликта пространства имен. При компиляции в IL нет никакой разницы между ними.

Answer 26

Также рассмотрим Int16. Если вам нужно хранить целое число в памяти в вашем приложении и вас беспокоит объем используемой памяти, то вы можете использовать Int16, поскольку он использует меньше памяти и имеет меньший минимальный / максимальный диапазон, чем Int32 (то есть, что такое int.)

Answer 27

Согласно непосредственному окну в Visual Studio 2012 Int32 - это int, Int64 - это длинный. Вот вывод:

sizeof(int)
4
sizeof(Int32)
4
sizeof(Int64)
8
Int32
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648
Int64
long
    base {System.ValueType}: System.ValueType
    MaxValue: 9223372036854775807
    MinValue: -9223372036854775808
int
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648

Answer 28

Использование Int или Int32 - это то же самое, что просто упрощение кода для читателя.

Используйте Nullable вариант Int? или Int32? при работе с базами данных на полях, содержащих ноль. Это избавит вас от многих проблем во время выполнения.

Answer 29

Некоторые компиляторы имеют разные размеры для int на разных платформах (не специфично для C#)

Некоторые стандарты кодирования (MISRA C) требуют, чтобы все используемые типы имели заданный размер (т. Е. Int32, а не int).

Также полезно указывать префиксы для переменных разных типов (например, b для 8-битного байта, w для 16-битного слова и l для 32-битного длинного слова => Int32 lMyVariable)

Вы должны быть осторожны, потому что это делает ваш код более переносимым и более легким в обслуживании.

Переносимость может быть неприменима к C#, если вы всегда собираетесь использовать C# и спецификация C# никогда не изменится в этом отношении.

Поддерживаемое ihmo всегда будет применимо, потому что человек, обслуживающий ваш код, может не знать об этой конкретной спецификации C# и пропустить ошибку, если время от времени int становится больше 2147483647.

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

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

Answer 30

Это 2021 год, и я прочитал все ответы. Большинство говорит, что это в основном то же самое (это псевдоним), или, это зависит от того, «что вам нравится», или «по соглашению использовать int...». Ни один ответ не дает вам четкого понимания, когда, где и зачем использовать over. Вот почему я здесь.

В 98% случаев вы можете уйти, и это прекрасно. Какие еще 2% ?

IO с записями (структура, собственные типы, организация и сжатие). Кто-то сказал, что бесполезное приложение - это приложение, которое может читать и обрабатывать данные, но на самом деле не способно записывать новые данные в определенное хранилище. Но чтобы не изобретать велосипед, в какой-то момент тем, кто имеет дело со старыми данными , необходимо найти документацию о том, как их читать. И скорее всего , они были составлены из эпохи , гдевсегда было 32-битным целым числом.

Это случалось раньше, когда некоторым было трудно вспомнить это байт, это слово это двойное слово, но сколько битов это было? И что, скорее всего , повторится на на платформа ... где (будущие) мальчики никогда не слышали о "по соглашению, используйте int вместо Int32". Это 2%, где имеет значение. MSDN говорит, что сегодня его рекомендуется использовать, не имеет значения, обычно он работает с текущей версией C#, но это может быть удалено на будущих страницах MSDN, в 2028 или 2034 году? Все меньше и меньше людей а также поединки сегодня, но два десятилетия назад они были обычным явлением. То же самое произойдет и в случае работы с данными точной фиксированной длины.

В памяти , A ( ) может быть до тех пор, пока его дробная часть равна нулю, она положительна или равна нулю и не превышает 65535. Но внутри файла она должна быть , Длина 16 бит. И когда вы читаете документацию о файловой структуре из другой эпохи (внутри исходного кода), вы понимаете, что существует 3545 определений записей , некоторые из которых вложены внутри других, причем каждая запись имеет от пары до сотен полей разных типов.

Где-то в 2028 году мальчик подумал, что он может просто уйти, нажав Ctrl-H-ing to, только целое слово и сопоставив регистр ... ~67000 изменений всего решения. Нажмите Run и все равно получите CTD. Хлопок хлопок хлопок. Пойдите и определите, на какие вы должны были поменять, а какие - на . Также стоит отметить полезны, когда вы имеете дело с терабайтами данных (виртуальное представление всей планеты в облаке, загрузка по запросу и рендеринг на экран пользователя). Указатели работают очень быстро в ~1% случаев, когда требуется вычислить так много данных в реальном времени, что вам придется торговать небезопасным кодом. Опять же, нужно придумать действительно полезное приложение, вместо того, чтобы тратить время на перенос времени на управляемое. Так что будьте осторожны, уже 32-битное или 64-битное? Можете ли вы обойтись своим кодом, не заботясь о том, сколько байтов вы читаете / пропускаете? Или просто иди ...

Еще более фактическим примером является файл, содержащий обработку данных и соответствующие им команды (методы в исходном коде), такие как внутреннее ветвление (условное продолжение или переход в случае сбоя теста):

запись в файле говорит: если значение равно someConstant, перейти к. Где это целое число, представляющее относительный указатель внутри файла (вы можете вернуться к началу файла до 32768 байт или до 32767 байт ниже). Но 10 лет спустя платформы могут обрабатывать большие файлы и большие данные, и теперь у вас есть относительный адрес. Ваш метод в исходном коде был назван , как бы вы назвали новую? или ? Не могли бы вы также переименовать старый метод или ? Затем, десять лет спустя, вы получаете новую команду с длинным (Int64) относительным адресом ... А как насчет 128-битной команды 10 лет спустя? Будьте последовательны ! Принципы - это здорово, но иногда логика лучше.

Проблема не во мне или в том, что вы пишете код сегодня , и нам кажется, что это нормально. Он находится на месте одного парня, который пытается понять, что мы написали 10 или 20 лет спустя, сколько времени (= денег) стоит придумать работающий обновленный код? Явные или повторяющиеся комментарии действительно сэкономят время. Какой из них ты предпочитаешь? или .

Кроме того, работа с внешними данными с других платформ или директивами компиляции - это концепция (сегодня это включает Interop, COM, PInvoke...), и от этой концепции мы не можем избавиться , независимо от эпохи, потому что для обновления (переформатирования) требуется время. datas(например, посредством сериализации). Обновление DLL до управляемого кода также требует времени. Нам потребовалось время, чтобы оставить ассемблер позади и перейти на полный C. Нам нужно время, чтобы перейти от 32-битных данных к 64-битным, но нам все еще нужно заботиться о 8 и 16 битах. Что дальше в будущем? Переходить со 128 бит на 256 или сразу на 1024? Не думайте, что ключевое слово, явное для вас, останется явным для парней, читающих вашу документацию 20 лет спустя (а документация обычно содержит ошибки, в основном из-за копирования / вставки).

Итак, вот оно: где сегодня использовать Int32 вместо int?

Это когда вы создаете код, учитывающий размер данных (ввод-вывод, сеть, кроссплатформенные данные ...), и в какой-то момент в будущем - может быть, спустя десятилетия - кому-то придется понимать и переносить ваш код. Основная причина - эпоха. 1000 строк кода, можно использовать , 100000 строк, это уже не так. Это редкая обязанность , которую придется выполнять лишь немногим , и, черт возьми, у них есть борьба, если бы только некоторые были немного более явными, вместо того, чтобы полагаться на « условно » или « это выглядит красиво в среде IDE, Int32 такой уродливый » или « они такие же, не беспокойтесь, писать эти два числа и удерживать клавишу Shift - пустая трата времени », или « int однозначно », или « те, кому не нравится int, просто фанаты VB - вперед выучите C#, новичок"(да, вот в чем смысл нескольких комментариев прямо здесь)

Не воспринимайте то, что я написал, как общее восприятие или попытку продвигать Int32 во всех случаях. Я четко изложил конкретный случай (поскольку мне кажется, что это было неясно из других ответов), чтобы защитить тех немногих, кого их руководители обвиняют в том, что они причудливые письма, и в то же время тот же самый руководитель не понимает, что нужно так долго, чтобы переписать эту C DLL на C#. Это крайний случай, но, по крайней мере, для тех, кто читает, "Int32" имеет по крайней мере одну цель в своей жизни.

Этот вопрос можно обсудить дальше, перевернув вопрос: почему бы просто не избавиться от , и все другие варианты в будущих спецификациях C#? Что это будет означать?