Выбор типа для числа. Int или не Int

Доброго дня форумчанам.

Я недавно начал писать на C# и меня беспокоит вопрос правильного выбора типа для числовых переменных (не считая выбор между int и double, т.к. они реализуют различный, как мне видится, функционал).

Мне не совсем понятно, почему в большинстве примеров используется int, чем это мотивируется. Только ли для простоты примера? Помнится где-то читал, что хранение памяти в 64битных системах организовано таким образом, что там выгоднее использовать int. Так ли это или я не то запомнил?

Если я задаю динамический массив или цикл for менее 255 элементов(итераций), имеет ли смысл менять привычный int на byte? (в случае массива, написать свой итератор с byte)

Имеет ли смысл делать поля ID в форматах uint/ushort(когда классов не ожидается много) для явного исключения отрицательных значений?

Я пока не ограничен по времени и хотел бы писать, по возможности, более оптимальный код, но, к сожалению, нету примеров/наставников

Подскажите, чем вы руководствуетесь при выборе типа для числовых переменных?

0

Сообщение от Kamerton не совсем понятно, почему в большинстве примеров используется int, чем это мотивируется.

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

Сообщение от Kamerton Если я задаю динамический массив или цикл for менее 255 элементов(итераций), имеет ли смысл менять привычный int на byte?

Нет, если не работаете с интеропом.

Сообщение от Kamerton Имеет ли смысл делать поля ID в форматах uint/ushort(когда классов не ожидается много) для явного исключения отрицательных значений?

Нет, если не работаете с интеропом.

Сообщение от Kamerton чем вы руководствуетесь при выборе типа для числовых переменных?

Целое исло — int, большое целое число — long.
Вещественное число для вычислений вроде физических — double.
Вещественное число для вычисления финансов — decimal.
Интероп, требующий беззнаковых чисел — ushort, uint, ulong.
Прочий интероп — byte, short, int, long.
Работа с данными вроде файловых или сетевых — byte.

3

Сообщение от Kamerton Мне не совсем понятно, почему в большинстве примеров используется int, чем это мотивируется

С точки зрения быстродействия процессора, манипуляции с 1 байтом, с 2 байтами и с 4 байтами - одинаково по скорости (поскольку процессор все равно оперирует 32 разрядными регистрами). Поэтому нет особого смысла использовать 1 или 2 байтовые локальные переменные. Ни памяти ни скорости вы от этого не выиграете.
Кроме того, многие функции заточены именно под int. Например функции из Math. Или, например если вы обращаетесь к элементу массива, то в качестве индекса обычно принимается int. Если же у вас будет иной тип, то он будет преобразовываться к int. А это лишние операции.

Другие дело хранение объектов в памяти. Если число явно не может быть отрицательным, то лучше конечно хранить в беззнаковом виде.

Имеет ли смысл делать поля ID в форматах uint/ushort(когда классов не ожидается много) для явного исключения отрицательных значений?

Имеет. С точки зрения сохранения целостности данных.

2

Сообщение от Kamerton чем вы руководствуетесь при выборе типа для числовых переменных?

Наверное, удобством. Тип Int32 самый удобный. Он может вместить достаточно большое целое число, а Int64 только при необходимости.
Так же, надо учитывать, что при любых арифметических операциях более низкие целые (byte, short) неявно приводятся к Int32, и в таких случаях требуется явное приведение типов, что неудобно.
Что касается знаковых-беззнаковых целых, тут все зависит от задачи, которую вы решаете.

1

Сообщение от Storm23 Если же у вас будет иной тип, то он будет преобразовываться к int. А это лишние операции.

преобразование типа накладная операция?

Как быть, когда допустим стандартный класс List (ну или другие классы из библиотеки) использует int в качестве индекса, а длинна у меня должна быть больше, чем вмещает int, можно как то решить эту проблему или надо свой список делать?

PS давно меня мучают эти вопрос с типами, но вот все ни как повода не было спросить.

0

Сообщение от VLK можно как то решить эту проблему или надо свой список делать?

А разве Generic (LIst<T>) отменили?

1

insite2012, может я что то не так понял, я имею ввиду я создаю список строк:
и элементов в этом списке будет больше, чем вмещает int, как мне тогда обращаться к элементам этого списка:

0

Сообщение от VLK как мне тогда обращаться к элементам этого списка

Ааа, вот вы про что... Ну в самом простом случае - взять исходники, к примеру, List<T> и переписать с другим основанием (long, к примеру).

1

VLK,

This would not be useful if it was allowed. The CLR has a limit on the maximum size of an object at 2GB. Hence it's not even possible to construct an array where a long index would be useful.

Объекты больше 2гб (включая х64) можно строить только начиная с .Net 4.5

Добавлено через 6 минут
Тем более ничего хорошего из этого всё равно не выйдет. Т.к. интерфейсы IList<T>, IReadOnlyList<T>, сам список, все свойства (Count, Size) имеют тип int. В результате нужно переписывать полностью весь неймспейс System.Collections.Generics для работы с лонгами.

Добавлено через 1 минуту
Так что даже если взять исходники - нужно будет писать класс, с которым нельзя будет нормально работать через интерфейсы (все элементы после первых двух миллиардов будут недоступны).

1

insite2012, Psilon, понятно, у меня бывает появляется какой то вопрос (не к селу не к городу) и вот не успокоюсь, пока не получу ответ.
Мне вот интересно, а почему изначально все эти List и т.д. не используют uint, вроде как отрицательный индекс быть не может.

ну или может, что то я такое припоминаю, вот только лучше обойтись без отрицательных, но за то в 2 раза больше, чем вмещает при использовании int.

И еще, что бы не переделывать под long, можно сделать класс обертку, в который засунуть несколько списков и от этого отталкиваться, от индекса вычитать / прибавлять, столько, сколько первый вмещает список, что бы рыться во втором списке, как то так.

0

Сообщение от VLK почему изначально все эти List и т.д. не используют uint

Со слов Липперта, все эти uint, short и прочие sbyte в язык добавили только для того, чтобы имелась возможность взаимодействовать с другими языками, имеющими эти типы.
Если бы не это, то в шарпе было бы четыре числовых типа: int, long, double, decimal.

0

Сообщение от VLK Мне вот интересно, а почему изначально все эти List и т.д. не используют uint, вроде как отрицательный индекс быть не может.

А вот пример:
Можете навскидку сказать, что будет при выполнении этого кода?
А вот потому uint и не используют...

Добавлено через 8 минут
kolorotur, Че и даже byte не нужен? Тогда мы скатимся в Java...

Сообщение от kolorotur Вещественное число для вычислений вроде физических — double.

Как то у вас все сильно упрощено. Например вся графика (как 3D так и 2D) использует float а не double.
Я долгое время занимался разработкой статистического софта и почти везде использовал float вместо double. Почему? Потому что он в два раза меньше занимает памяти. На больших объемах данных это существенно.
Без byte тоже не обойтись. Например тип Сolor содержит 4 байта, а если использовать Java-like подход - то будет все 16. Оно надо?
Да, типы uint и ulong - не очень часто используются, тем не менее иногда полезны. Хотя бы для того, что бы подчеркнуть, что данное значение не может быть меньше нуля.

0

Storm23, бесконечный цикл когда попытается нулю сделать --

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

0

Сообщение от Storm23 Че и даже byte не нужен?

Сообщение от kolorotur Работа с данными вроде файловых или сетевых — byte.

Сообщение от Storm23 Например вся графика (как 3D так и 2D) использует float а не double.

Legacy + заточенная под нее архитектура.
Вангую, что рано или поздно 64-битные вычисления полностью вытеснят 32-битные, как 32-битные в свое время вытеснили 16-битные.

Сообщение от Storm23 Как то у вас все сильно упрощено.

Да я в принципе люблю когда все просто

0

Сообщение от kolorotur Legacy + заточенная под нее архитектура.

Неа, это не legacy. Просто в графике не нужна точность double. А вот двойной объем памяти под double - пустая трата ресурсов.

Сообщение от kolorotur Вангую, что рано или поздно 64-битные вычисления полностью вытеснят 32-битные, как 32-битные в свое время вытеснили 16-битные.

А зачем вытеснять 32 битный int, если он подходит для подавляющего числа рссчетов?

0

кстати, произвел замер преобразования, uint или long достаточно быстро преобразуются в int, можно сказать почти как без преобразования, а вот ulong и float чуть по хуже, но тоже разница не велика, при объеме.

0

VLK,прежде чем забивать голову лучше задаться вопросом - а нафига?
памяти-то хватит на списки больше int.max? даже список с пустыми ссылками займет 16 гигабайт просто на самого себя, не считая данных на которые ссылки указывают
на 32 битной системе он бы занял всего 8 гб, но 32 битная система не умеет в 8 гб
2 миллиарда объектов это мягко говоря дофига, даже в полноценных СУБД столько не накапливается, кроме совсем уж диких мест вроде ютуба или фейсбука где сидят десятки миллионов юзеров

1

m0nax, у меня фобия, я всё всегда пытаюсь сделать идеально, отсюда и вытекают, такие вопросы.

0

Сообщение от VLK у меня фобия, я всё всегда пытаюсь сделать идеально, отсюда и вытекают, такие вопросы.

Вот-вот-вот... (с) И у меня также... И не поймёшь, то ли лечиться, то ли в QA развиваться...

Благодарю за развёрнутые ответы Похоже, что мои мечты о byte'овых массивах всё же больше идеалистические, чем практические, по крайней мере в рамках C#...

Сообщение от kolorotur Нет, если не работаете с интеропом.

А можете чуть подробнее, пожалуйста... Интероп - это ведь COM? А то COM Interop на msdn меня смущает... Какое понятие больше: COM, Interop или они эквивалентны?)

0

Сообщение от Kamerton Интероп - это ведь COM?

И СОМ в том числе.
Интероп — это в принципе работа с другой средой. Например, использование сишных библиотек через DllImport — это тоже интероп.
Работа с офисом — тот еще интероп.
Ну и так далее.

Добавлено через 2 минуты

Сообщение от Storm23 Просто в графике не нужна точность double. А вот двойной объем памяти под double - пустая трата ресурсов.

Сообщение от Storm23 А зачем вытеснять 32 битный int, если он подходит для подавляющего числа рссчетов?

Возразить мне вам нечем, но все равно имеется уверенность в том, что 64-битные вычисления вытеснят 32-битные.
Хотя бы ради унификации и упрощения, к которым видно явное стремление на протяжении всей жизни того же шарпа.
А память только дешевеет.

0