Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types
Умно?
Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.
Что скажете?
Re: 64 бита для целого без вариантов - добро или зло?
Смотря для какого языка. Так делать нельзя, если:
— язык должен иметь возможность получать доступ к железу;
— язык предполагает парсинг и сериализацию бинарных данных/файлов/протоколов.
Re: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, 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 байт.
Как без такой возможности писать высокоэффективные приложения с умеренным потребленем памяти, я не понимаю.
Re: 64 бита для целого без вариантов - добро или зло?
S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.
S>Что скажете?
1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,
и соответственно заставлять для этого заводить какой-то новый тип, я бы не назвал удобным
2. Кэш процессора на данный момент это один из ключевых факторов производительности,
и невозможность впихнуть туда больше чисел удручает
Re[2]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, swame, Вы писали:
S>Тип меньшего размера чем 64 бит нужны, только если структурв типа record не выравнивают внутреннее представление на 8 байт для 64-разрядного приложения или на 4 байта для 32-разрядного. В противном случае все равно переменная займет 8 байт.
Бывает не только record, но и банальный массив
Re: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, 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++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.
Языки же которые вообще не имеют контроля разрядности мусорные по своей сути. Обычно это какие-нибудь скрипты, где всем плевать на производительность и память.
У меня есть предположение, почему такое произошло. Традиционно есть адресация в оперативной памяти, а есть данные не являющиеся адресами. И на ранних стадиях разработки языков об этом не задумывались смешивая вместе. А потом пошло поехало.
Re[2]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, velkin, Вы писали:
V>Не нужно было делать никаких char, short, long, long long и прочего. Потому в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.
Здравствуйте, Shmj, Вы писали:
S>Так добавили ж уже:
S>int8_t S>int16_t S>int32_t S>int64_t
Добавили, когда было уже слишком поздно. К моменту когда их добавили, было уже написано дофига кода, который уже работать не будет. Теперь тебе нужно ооочень постараться, чтобы старые бинари прочитать.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, Философ, Вы писали:
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).
Это не встроенные фундаментальные типы, а алиасы. Разница, хотя бы, в том, что для встроенных типов не надо тащить #include <cstdint>. Что подходит под определение "в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток".
Re[3]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, 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-байтным.
Было очень увлекательно читать на профильных форумах, как народ пытается отломать ограничения
_____________________
С уважением,
Stanislav V. Zudin
Re[4]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, T4r4sB, Вы писали:
Z>>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,
TB>>Это где же? Для индексов и размеров оно вредит. Для битовых операций?
A>Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.
А еще он создает кучу гемора, не отлавливаемого компилятором со всеми варнингами, когда размер или индекс участвует в формуле где есть такая казалось бы невинная операция вычитания. Нафиг. Показывать ограничения на результат надо другими способами.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, 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 в данном случае? Правильно ли были записано присваивание? И т.д.
Re[6]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, Alekzander, Вы писали:
A>Это надо смотреть на конкретном примере. Правильно ли был выбран uint в данном случае? Правильно ли были записано присваивание? И т.д.
Уинт был выбран неправильно но не мной, он вшит в язык намертво.
Присваивание конечно неправильно. Пишу тупо a=b вместо a=b as isize.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
