Говорят *int64_t не нужен. float64_t хватит всем

Впихнуть unix timestamp из Protobuf в OpenAPI для дальнейшей генерации в TypeScript / Dart.

В swagger оно появлялось как "type": "string", "format": "int64" вместо кошерного "type": "integer", "format": "int64", с дальнейшей ломкой всех типов.

В ходе экспериментов выяснилось что из исходного типа оно следующее делает:

• uint64 / int64 → string / int64
• uint32 → integer / int64
• int32 → integer / int32

А всё потому что «53 бита хватит всем!».

Да сейчас модно жи только INT8 для AI

Так их и абъюзят. В ядре через них ошибки возвращают :D

Массив из u8. Что логичнее u64, так-то говоря.

Смешали ужа с ежом (целочисленный тип с плавающей запятой) и получили метр колючей проволоки. Они же из разных категорий.

Больше тормозов богу тормозов. Поверх тормозов от float вместо int, что на фуфыксе сразу уполовинивает производительность.

Массив?! Это точно логичнее? А с хера ли это логичнее? То что можно сделать за один оператор теперь будем делать циклами или за восемь операторов. И плюс оператор взятия элемента по индексу. Бл***, ну слов нормальных нету, от такой «логики».

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

А, т.е. и cpu должны подстраиваться под это ублюдство?

lisp машину в каждый лопатофон

Массив?!

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

Это точно логичнее?

Депендс. В условиях бинарных данных (из файла например) никто не гарантирует, что остаток от деления индекса поля на 4, 8 или даже 2 всегда будет нулевым, так что взяв массив из 64битных интов можно создать себе лишнюю работу, когда окажется, что код, написанный для выравненных данных, придётся переписывать, когда в 100500 рекорде вдруг окажется 16битное поле и всё сдвинет.

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

Конпеляторы умеют циклы векторизировать. Может оказаться, что оптимизация работы с байтами через 64битные инты не позволит заюзать 128/256 или 512битные регистры. Если семантически это просто байты, то может лучше их байтами и оставить.

Без -O3 не умееют, а почти все собирают с -O2.

Конпеляторы умеют циклы векторизировать.

Оффтоп конечно, но как же бесит - не первый раз натыкаюсь: откуда вот это вот «коНпелять»?? CoMpilator, M, мать вашу.

А еще вот эти вот «не умет в …»

Без -O3 не умееют, а почти все собирают с -O2.

Сейчас проверил - gcc 13.2.1 простой цикл по массиву с байтами с -O2 всё упаковал в xmm*. Может какие-то сложные варианты и требуют O3, конечно, но просто независимая обработка битов в байтах и на O2 векторизуется. На O1 - нет.

Оффтоп конечно, но как же бесит - не первый раз натыкаюсь: откуда вот это вот «коНпелять»?? CoMpilator, M, мать вашу.

Ну заменю я в слове конпелять «н» на «м», так тут же скажут, что после «п» идёт «и», а не «е». Не, не стоит оно того.

И, кстати, если уж строить из себя знатоков английского, то не «compilator» наверное.

тормозное говнище

Для тормозного говнища оно из-за современных компиляторов на удивление быстрое, потому что не так страшен JS, как те, кто на нём пишет.

И, кстати, если уж строить из себя знатоков английского

Ни в одном глазу. Тут есть другие «специалисты». Но конкретно это - очевидные вещи. И коверкание. Которое я до сих пор не понимаю откуда пришло.

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

Да не нужно это убожество использовать как аргумент.

В условиях бинарных данных (из файла например)

А это вообще не js-иков дело, как там бинарные данные читать. И к проблемам там может привести все что угодно, там вообще миллион того, что может пойти не так. Это как говорить, что раз в скоплении людей можно подхватить простуду, то значит не не нужно вообще в электричках ездить.

КоМпИляторы умеют циклы векторизировать.

Да что это за манера у js-иков и компании: давайте писать через жопу. чтобы компиляторы все исправляли? Поэтому у вас все тормозит и память выжирает. А может писать так, чтобы ничего исправлять не нужно было?

Может оказаться, что оптимизация работы с байтами через 64битные инты не позволит заюзать 128/256 или 512битные регистры.

Как в случае с бинарными данными, может что угодно произойти, не нужно этих может - не может. Если в каком то конкретном случае int64 не подходит (только по причине ошибок или других объективных причин, а не вот этих «использовать для битов семантически неверно», тьфу бл***) то их и не используют.

Если семантически это просто байты, то может лучше их байтами и оставить.

А это кто придумал/решил? Семантически это то, что представляет, какую именно сущность. Например сообщение с состоянием от некоторой железяки - это и есть семантически «сообщение с состоянием» и если оно использует более 8 бит, то все эти биты - это представление этого состояния. А сколько ты там нащитал бит/байт - это не семантически, это размер.

И, кстати, если уж строить из себя знатоков английского

Ты на русском пишешь, при чем в данном случае английский? По-русски будет «компилятор/компиляция».

Да что это за манера у js-иков и компании: давайте писать через жопу. чтобы компиляторы все исправляли?

«через жопу» - это оценочное суждение, не надо пытаться по-тихому пропихнуть его, если не можешь аргументировать нормально. Правильнее «давайте писать свои намерения». Если надо проксорить байты - пиши ксор с байтами, не делай предположений о железяке и не «оптимизируй» под неё. Оптимизацией под удобство железа занимается коНпЕлятор.

А это кто придумал/решил?

Ну ты спросил про битовые операции, не? С чего ты решил, что битики должны паковаться по 32/64?

Например сообщение с состоянием от некоторой железяки - это и есть семантически «сообщение с состоянием» и если оно использует более 8 бит, то все эти биты - это представление этого состояния. А сколько ты там нащитал бит/байт - это не семантически, это размер.

А если менее? А если много более?

Подбирать удобный тебе пример - ну такое.

Давай чтоб понятно объясню тебе оригинальный вопрос: почему логично. Вот есть у тебя 4 байта состояния, каждый бит что-то значит. Ты можешь представить их как uint32_t. Ты так и сделаешь, конечно, и не только ты, скорее всего любой так сделает, потому что массив 4 байта городить неудобно, передавать его, ну нафиг. Но это в общем-то будет в чём-то как раз «через жопу». И это даже не потому, что как-то нелогично, когда у тебя 20 битовых флагов кодируются одним простым типом, и проверяются по маске, а при переходе с 64флагов на 65 вдруг появляется какой-то bitset и весь код работы с флагами переписывается. Используя uint32_t ты как бы подразумеваешь, что у тебя есть некое 4байтное число, и переполнение бита №7 должно привести к переносу в бит №8. А это не так, это просто «запихал всё в 1 значение». Конечно, на это можно возразить, что бит№7 ничем не лучше бита №6, и поэтому байт тоже не катит, но на это тебе возразят, что катит, так как память у нас адресуется по байтам и от этого никуда не деться. Однако в некоторых языках существует возможность работы с битовыми полями и там в общем-то такой подход поощряется. Но если нет, то лучше байты, это как бы честное сообщение читателю: «делаю немного через жопу, но только от того что лучшего варианта нет».

элегантно решается использованием __int128

И коверкание.

Именно.

Которое я до сих пор не понимаю откуда пришло.

Ну как диванный специалист по всему, включая филологию/лингвистику я могу объяснить: для жаргона характерно коверканье. Всякая дОбыча, например, или договорА. Есть гипотеза, что таким образом коверкающий показывает, что он с обсуждаемой темой не «на Вы», а на «эй, ты». Понятно, что делается это несознательно, а просто приятно коверкать. Но это не точно. В любом случае, подобные изменения неизбежно возникают и всерьёз душнить от этого себе дороже.

<– там комната людей, которых очень пердолит мнение вебмакаки с телеги.

А всякие int64/uint64 это от лукавого. Должен быть только number64

То-то [url]int128 и больше изобретают[/url] [url=«https://learn.microsoft.com/ru-ru/dotnet/api/system.int128?view=net-8.0»]все кому не лень[/url] и AVX512 за каким-то хреном придумали.

Это не «элегантно», это пример, демонстрирующий кривизну подобного подхода.

фак маркдаунов, лоркод форева,

короч:

int128 и больше изобретают –> https://github.com/cpp-ru/ideas/issues/84

кому не лень –> https://learn.microsoft.com/ru-ru/dotnet/api/system.int128?view=net-8.0

Есть гипотеза, что таким образом коверкающий показывает, что он с обсуждаемой темой не «на Вы», а на «эй, ты».

Плохая гипотеза по Оккаму и по Хэнлону. Не стоит объяснять заговором, то что можно объяснить членоруком. Плодить сущности соответственно тоже. Просто мастерюги и прочие «профи» редко сочетают свои тех. скиллы с элементарной грамотностью – а потом «тут так принято»(тм).

«через жопу» - это оценочное суждение,

Массив из u8. Что логичнее u64

А это не оценочное.

Мда. И кстати использовать цикл там или несколько операторов там, где можно обойтись одним (и плюс еще надеется, что компилятор это исправит) - это именно «через жопу» и есть.

Ну ты спросил про битовые операции, не? С чего ты решил, что битики должны паковаться по 32/64?

Не должны, а могут. И в случае этих самых «могут» это проще и удобнее.

А если менее?

Неочевидно?

А если много более?

Специальные типы (std::bitset), неочевидно?

Ты так и сделаешь, конечно, и не только ты, скорее всего любой так сделает, потому что массив 4 байта городить неудобно, передавать его, ну нафиг. Но это в общем-то будет в чём-то как раз «через жопу».

Неужели. Не может быть.

И это даже не потому, что как-то нелогично, когда у тебя 20 битовых флагов кодируются одним простым типом, и проверяются по маске, а при переходе с 64флагов на 65 вдруг появляется какой-то bitset и весь код работы с флагами переписывается.

Мы доказываем отсутствие необходимости фичи тем, что при гипотетическом изменении логики текущая реализация может не подойти. Браво! Давайте сейчас же выбросим все двс авто и пересядем на электрички, хер с ним, что они менее удобны в части зарядки/заправки, но ведь вдруг нефть завтра закончится?

Используя uint32_t ты как бы подразумеваешь, что у тебя есть некое 4байтное число, и переполнение бита №7 должно привести к переносу в бит №8. А это не так, это просто «запихал всё в 1 значение». Конечно, на это можно возразить, что бит№7 ничем не лучше бита №6, и поэтому байт тоже не катит, но на это тебе возразят, что катит, так как память у нас адресуется по байтам и от этого никуда не деться. Однако в некоторых языках существует возможность работы с битовыми полями и там в общем-то такой подход поощряется. Но если нет, то лучше байты, это как бы честное сообщение читателю: «делаю немного через жопу, но только от того что лучшего варианта нет».

Госпади, какая же это сумбурная херь.

Используя uint32_t ты как бы подразумеваешь

С хера ли? Зависит от конкретного сценария использования

Конечно, на это можно возразить, что бит№7 ничем не лучше бита №6, и поэтому байт тоже не катит, но на это тебе возразят, что катит, так как память у нас адресуется по байтам

Что это за аргумент? Нет серьезно, это что, какая-то диалектика из параллельной вселенной? Все. Тему можно закрывать, раз память вся на байтах, то пусть будет только массив из байт. Это доказательство? Или камеди клаб?

Но если нет, то лучше байты, это как бы честное сообщение читателю: «делаю немного через жопу, но только от того что лучшего варианта нет».

это оценочное суждение

меньше 64бит процев кроме ембеддед не встретить, потому заморачиваться лишний раз с меньшими типами нет смысла

Массив?! Это точно логичнее?

Ага. Прикинь тебе надо u24, а не u32. Сейчас ты скажешь «в си есть битовая размерность» и получишь массив, ограниченный 8 байтами.

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

Что ты несешь? Какие циклы? Проверка/установка флажка как были одной операцией, так и остались.

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

Байт остается целочисленный.

Плохая гипотеза по Оккаму и по Хэнлону.

Чувак, это факт. Просто в этой теме ты, видимо, так же некомпетентен, как и в программировании. И собственную некомпетентность сочетаешь с высокомерием.

Ага. Прикинь тебе надо u24, а не u32

А вас все аргументы, а «вот если…»

А вот если, то будем использовать специальные типы для битов.

Что ты несешь? Какие циклы? Проверка/установка флажка как были одной операцией, так и остались.

Ты все читал? Там предлагалось для операций с битами использовать массив байт.

Байт остается целочисленный

Ах бл. целый байт!? Ну прекрасно.

Мда. И кстати использовать цикл там или несколько операторов там, где можно обойтись одним (и плюс еще надеется, что компилятор это исправит) - это именно «через жопу» и есть.

Нет. Человека, который подменяет собой компилятор можно назвать только идиотом и никак иначе. И не надо, пожалуйста, писать про 1 оператор: это чисто подсовывание искусственного примера под предлагаемый вариант, в общем случае задача в любом случае требует массивов и циклов, разница только в размере элемента.

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

Не должны, а могут. И в случае этих самых «могут» это проще и удобнее.

Могут, и это будет называться «через жопу».

Специальные типы (std::bitset), неочевидно?

Ок, так и запишем: хранить биты в 16/32/64/128/256 и т.д битных регистров - кривой хак, способный облегчить жизнь нерадивому программисту в очень узком интервале задачи. Это и называется «через жопу».

Мы доказываем отсутствие необходимости фичи тем, что при гипотетическом изменении логики текущая реализация может не подойти. Браво!

Нет. Ты спросил почему логичнее делать в байтах. Я тебе ответил. Но ты не готов принять ответ, потому что он предельно прост и тебе обидно, что ты настолько затупил, вот и пытаешься придумать хоть что-то в защиту. Успокойся. Я не запрещаю тебе хранить флаги в инте. Не всегда имеет смысл писать качественно. Но ты должен осознавать, что это именно и есть то самое «через жопу».

Госпади, какая же это сумбурная херь.

Ну не я виноват в том, что ты до сих пор не узнал, что код пишется для чтения человеком. Вот такие люди теперь программизмом занимаются. Зато «компилятор» пишут через «м» :)

А вас все аргументы, а «вот если…»

Ну потому что мне вчера надо было.

Ты все читал? Там предлагалось для операций с битами использовать массив байт.

Иии? Расскажите мне сакральную разницу между одной атомарной записью и другой.

Ах бл. целый байт!? Ну прекрасно.

А ты можешь не истерить как пятилетняя девочка?

меньше 64бит процев кроме ембеддед не встретить, потому заморачиваться лишний раз с меньшими типами нет смысла

Мы говорим на разных языках. Забудь про железо. Тебя не должно беспокоить разрядность регистров, выравнивание и т.п., теперь этим поручено заниматься компиляторам. Ты, как программист, должен чётко и явно изложить, что тебе нужно, чтоб тебя понял компилятор, и, главное, человек-читатель. А как это сделать на предлагаемом железе решать должен компилятор. Такой современный положняк.

Человек же, играющий в «оптимизацию» через использование процессорного слова упрётся в ситуацию, когда ему придётся обрабатывать некратный размер или даже невыравненное начало и простой цикл по байтам потребует кучу дополнительного кода для обработки возможностей невыравненных концов интервала, и каждый читатель будет смотреть на эту хрень и вопрошать: «wat?».

Причём это похлеще джаваскриптового 017 + 1 != 018, в конце концов к тому как js обрабатывает 0 вначале можно привыкнуть, а тут постоянные сюрпризы.

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

Смотря что именно ты делаешь. На определенном уровне микрооптимизаций ты начинаешь жонглировать выравниванием в кешлинию, порядком полей в структурах, размером TLB и прочими неприятностями.

А ты можешь не истерить как пятилетняя девочка?

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

Ну потому что мне вчера надо было.

Опиши кейс где и как тебе нужно было.

Иии? Расскажите мне сакральную разницу между одной атомарной записью и другой.

А такая операция есть? Где? С примерами. Или ты описываешь гипотетическую операцию:

Bitset result = bitwise_or(bit_array_0, bit_array1);

?

Нет. Человека, который подменяет собой компилятор можно назвать только идиотом и никак иначе. И не надо, пожалуйста, писать про 1 оператор: это чисто подсовывание искусственного примера под предлагаемый вариант, в общем случае задача в любом случае требует массивов и циклов, разница только в размере элемента.

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

это чисто подсовывание искусственного примера под предлагаемый вариант

Ты делаешь точно так же: «а если бытов будет…»

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

Точно, вот смотрю я на тебя…

Могут, и это будет называться «через жопу».

Через жопу - это выкинуть простые типы и выдумывать какую то херню.

Ок, так и запишем: хранить биты в 16/32/64/128/256 и т.д битных регистров - кривой хак, способный облегчить жизнь нерадивому программисту в очень узком интервале задачи. Это и называется «через жопу».

«Дядя, ты дурак?» (с)

Так мало задач, но так много используется… Что-то не согласуется.

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

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

Ну не я виноват в том, что ты до сих пор не узнал, что код пишется для чтения человеком. Вот такие люди теперь программизмом занимаются. Зато «компилятор» пишут через «м» :)

Да ты че. Видывал я код от js-иков, там все прекрасно, как в китайской грамоте.

Опиши кейс где и как тебе нужно было.

24 бита в packed структуре. Ну и?

А такая операция есть? Где? С примерами.

Атомарная запись байта? Покажи где ее нет.

24 бита в packed структуре

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

И да, битов всегда кратно 8? Совпадение :-).

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

Зачем? Тебе хватит того, что это u24, где каждый бит значим.

Или ты описываешь гипотетическую операцию: Bitset result = bitwise_or(bit_array_0, bit_array1);

Я описываю вполне реальный set_bit() из того же ядра:

static inline void set_bit(int nr, void *addr)
{
	asm("btsl %1,%0" : "+m" (*(u32 *)addr) : "Ir" (nr));
}

Как же они обошлись без u64? Загадка.

А, т.е. и cpu должны подстраиваться под это ублюдство?

Ну под C же подстраиваются, хотя это сильно мешает развиваться.

И да, битов всегда кратно 8? Совпадение :-).

Потому что байт – минимальная единица адресации, чучело.

А по задачам флагов тоже всегда кратно 8, Обезьяна ты немытая. Ну конечно же, в предметных областях вообще все сущности строго под байты заточены и не бывает 23 флага состояний.

упрётся в ситуацию

Это твой основной прием: «рано или поздно…» Рано или поздно мы все умрем, так давайте уже мыться перестанем.

Что мне хватит, не твоя забота.

А по задачам флагов тоже всегда кратно 8, Обезьяна ты немытая. Ну конечно же, в предметных областях вообще все сущности строго под байты заточены и не бывает 23 флага состояний.

uint8_t flags[3];

set_bit(20, flags);

ну и?

Что мне хватит, не твоя забота.

Я не буду сливать код под NDA ради срачей, это не форумы war thunder.

Это твой основной прием: «рано или поздно…»

Ты забыл контекст. Если бы это был кодревью и я докопался бы до тебя по этому вопросу, ты мог бы возмущаться. Но мы обсуждаем гипотетический «как правильно» и тут рассматривать насколько предлагаемое решение хрупко.

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

Так «мыться» - это как раз делать по-человечески, а не так как ты предлагаешь.

А по задачам флагов тоже всегда кратно 8, Обезьяна ты немытая. Ну конечно же, в предметных областях вообще все сущности строго под байты заточены и не бывает 23 флага состояний.

Или ты про такой случай:

struct padded {
    uint8_t field:5;
    uint8_t flags:3;
};

Если да, то здесь та же срань. То, что битовые поля в сишке местами меняются на LE/BE – проблема сишки.