Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

Умно?

Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.

Что скажете?

Здравствуйте, Shmj, Вы писали:

S>Что скажете?

Смотря для какого языка. Так делать нельзя, если:
— язык должен иметь возможность получать доступ к железу;
— язык предполагает парсинг и сериализацию бинарных данных/файлов/протоколов.

Мне нравится, как в JS сделали. float64 без вариантов. Не знаю, кому нужны 64-битовые целочисленные значения, мне не нужны.

S>Умно?
Очередные юные оболтусы изобрели революционную идею что грамотность и ПДД опыт предков устарел и не нужен.

Здравствуйте, Shmj, Вы писали:

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

S>Умно?

S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.

S>Что скажете?

Тип меньшего размера чем 64 бит нужны, только если структурв типа record не выравнивают внутреннее представление на 8 байт для 64-разрядного приложения или на 4 байта для 32-разрядного. В противном случае все равно переменная займет 8 байт.
Как без такой возможности писать высокоэффективные приложения с умеренным потребленем памяти, я не понимаю.

Здравствуйте, Shmj, Вы писали:


S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.

S>Что скажете?

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

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

Здравствуйте, swame, Вы писали:

S>Тип меньшего размера чем 64 бит нужны, только если структурв типа record не выравнивают внутреннее представление на 8 байт для 64-разрядного приложения или на 4 байта для 32-разрядного. В противном случае все равно переменная займет 8 байт.
Бывает не только record, но и банальный массив

Здравствуйте, Shmj, Вы писали:

S>нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком
S>Умно?

Скорее очень глупо.

S>Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос.
S>Что скажете?

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

К тому же нет гарантий, что не понадобятся битовые поля или наоборот числа большей разрядности, например, 128, 256 и так далее. То есть идея я так понимаю просто слить в унитаз инструкции процессора, которые всё равно там будут пользуешься лично ты ими или нет.

Я считаю одним из весомых недостатков C/C++ является то, что разрядность типа int не определена для разных компиляторов. Изначально не нужно было делать такой тип, должен был быть int8, int16, int32, int64, ... , uint8, uint16, uint32, uint64.

Не нужно было делать никаких char, short, long, long long и прочего. Потому в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.

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

У меня есть предположение, почему такое произошло. Традиционно есть адресация в оперативной памяти, а есть данные не являющиеся адресами. И на ранних стадиях разработки языков об этом не задумывались смешивая вместе. А потом пошло поехало.

Здравствуйте, velkin, Вы писали:

V>Не нужно было делать никаких char, short, long, long long и прочего. Потому в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.

Так добавили ж уже:

int8_t
int16_t
int32_t
int64_t

https://en.cppreference.com/w/cpp/types/integer

Здравствуйте, vsb, Вы писали:

vsb>Мне нравится, как в JS сделали. float64 без вариантов...
надеюсь это шутка.

Здравствуйте, Shmj, Вы писали:

S>Так добавили ж уже:

S>int8_t
S>int16_t
S>int32_t
S>int64_t

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

Здравствуйте, Философ, Вы писали:

vsb>>Мне нравится, как в JS сделали. float64 без вариантов...
Ф>надеюсь это шутка.

The JavaScript Number type is a double-precision 64-bit binary format IEEE 754 value, like double in Java or C#.
...
Integers can only be represented without loss of precision in the range -2^53 + 1 to 2^53 — 1, inclusive (obtainable via Number.MIN_SAFE_INTEGER and Number.MAX_SAFE_INTEGER), because the mantissa can only hold 53 bits (including the leading 1).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number

Или шутка, что нравится?

Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, Shmj, Вы писали:


Z>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

Это где же? Для индексов и размеров оно вредит. Для битовых операций?

Здравствуйте, Shmj, Вы писали:

S>Так добавили ж уже:

S>int8_t
S>int16_t
S>int32_t
S>int64_t

S>https://en.cppreference.com/w/cpp/types/integer

Это не встроенные фундаментальные типы, а алиасы. Разница, хотя бы, в том, что для встроенных типов не надо тащить #include <cstdint>. Что подходит под определение "в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток".

Здравствуйте, T4r4sB, Вы писали:

Z>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

TB>Это где же? Для индексов и размеров оно вредит. Для битовых операций?

Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.

А InvalidValue надо явно задавать, через тот же 0xf..f. Или пользоваться исключениями/кодами возврата. Или типами с ? на конце.

Здравствуйте, Shmj, Вы писали:

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

S>Умно?

Так себе.
Выше умные люди уже привели аргументы.

S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт.

Я возражу. Помимо сериализации ещё есть и оперативная память. Нафига создавать семикратный оверхед на ровном месте?

S>Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.

S>Что скажете?

В одном из проектов мы использовали трюк с разным размером типа данных для ограничения бесплатной демо-версии программы.
В демо-версии максимальное число объектов было ограничено 125 — однобайтный знаковый тип (127 с учётом спецзначений). А в полнофункциональной версии этот тип был 4-байтным.
Было очень увлекательно читать на профильных форумах, как народ пытается отломать ограничения

Здравствуйте, Alekzander, Вы писали:

A>Здравствуйте, T4r4sB, Вы писали:

Z>>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

TB>>Это где же? Для индексов и размеров оно вредит. Для битовых операций?

A>Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.

А еще он создает кучу гемора, не отлавливаемого компилятором со всеми варнингами, когда размер или индекс участвует в формуле где есть такая казалось бы невинная операция вычитания. Нафиг. Показывать ограничения на результат надо другими способами.

Здравствуйте, Shmj, Вы писали:

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком

то что все целые 64 бита — это неправильно. С обработкой двоичных протоколов передачи данных будет неудобно (хотя может Dart на это не рассчитан).

Насчет того что все целые — знаковые... лично мне это нравится. И в джаве мне эта идея сразу понравилась, пока я не узнал что оказывается оператор >>> нормально работает только с int :(

например в джаве после такого:

 byte b=(byte)0xff;
 b>>>=1;

переменная b всё равно будет равна 0xff.

Получается смысл в >>> теряется для всех кроме int и возникают неудобства при обработки байтов в некоторых двоичных протоколах.
Почему они не сделали >>> для byte и short не понимаю

Здравствуйте, T4r4sB, Вы писали:

Z>>>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

TB>>>Это где же? Для индексов и размеров оно вредит. Для битовых операций?

A>>Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.

TB>А еще он создает кучу гемора, не отлавливаемого компилятором со всеми варнингами, когда размер или индекс участвует в формуле где есть такая казалось бы невинная операция вычитания. Нафиг. Показывать ограничения на результат надо другими способами.

Это надо смотреть на конкретном примере. Правильно ли был выбран uint в данном случае? Правильно ли были записано присваивание? И т.д.

Здравствуйте, Alekzander, Вы писали:

A>Это надо смотреть на конкретном примере. Правильно ли был выбран uint в данном случае? Правильно ли были записано присваивание? И т.д.

Уинт был выбран неправильно но не мной, он вшит в язык намертво.
Присваивание конечно неправильно. Пишу тупо a=b вместо a=b as isize.