int в си больше не нужен?

PS реквестирую современный подход к шаблонам в printf. Чтобы не %d а %u8, %i32

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

Грепай «Format macro constants» там.

реквестирую современный подход к шаблонам в printf

Современный подход это не использовать printf

PS реквестирую современный подход к шаблонам в printf. Чтобы не %d а %u8, %i32

Макросы из inttypes.h. Не знаю, можно ли считать их современными, это C99.

Так всё и есть.

(u)intXX_fast_t для считаная и (u)intXX_t для хранения

А мог бы использовать (u)int_leastXX_t для всего

Так и stdbool.h с тех же времён. Но до сих пор дефайнят свой.

Ты обосрался, 16бит тормознее 32бит.

Насколько я знаю, в Rust привели систему типов в порядок без всего этого сишного бардака по типу ‘long long long’ is too long for GCC" и прочих странных несуразностей.

Кто писал на Rust что-нибудь под Embedded, PC и разные архитектуры, может прояснить этот момент? Действительно ли стало удобнее?

int в Си нужен, т.к. стандарт. Да, 89 года. Да, неудобно, т.к. 2 раза поменялась архитектура (16bit -> 32bit -> 64bit). Никто не говорил, что будет легко, но люди как-то изворачиваются.

int в Си нужен, т.к. стандарт

Богом данный, на каменных скрижалях написанный.

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

НО КАК ТОГДА ПРОГРАММИРОВАТЬ ВАШ PDP-11?

У меня до сих пор 8 (:

Насколько я знаю, в Rust привели систему типов в порядок

u8fast, i32fast, ... имеются из коробки?

Насчёт остальных: char и short это по сути синонимы к int8 и int16. Хотя теоретически где-то они могут увеличить свою битность, но вряд ли это случится (слишком много кода завязано на это). Хотя использовать их вместо явного указания битности причин вроде нет. Хотя, с другой, использовать для строк тип char* как-то красивее чем int8*, а там, где char, там и unsigned char (вместо uint8).

long означает «не меньше 32 бит, но если не сложно (=не требует спец. логики) то поддержим 64». long long = «64 бита и может быть когда-нить больше, если проц нативно поддержит». То есть некоторое автоматическое масштабирование лимитов программы на новые процы. При переходе 32 -> 64 смысл в этом точно есть, дальше - не знаю.

Насчёт int. У него та же роль была при переходе 16->32. Много старого софта автоматом подняло свои лимиты просто перекомпиляцией когда-то. Сейчас же это синоним к int32. С одной стороны, если ты всё ещё думаешь о совместимости с 16-бит архитектурами, то int стоит использовать там, и только там, где прога не сломается от вставки вместо него int16 (это позволит на указанных архитектурах экономить память и такты проца). С другой, если ты про них не думаешь, вопрос несколько теряет смысл ввиду int = int32, и переходит в плоскость стиля кодинга.

PS реквестирую современный подход к шаблонам в printf. Чтобы не %d а %u8, %i32

Я себе кастомный printf сделал с удобными шаблонами, под это в том числе. Хотя они и в дефолтном есть вроде но неудобные.

Осознал что чистый int неизвестно какого размера мне перестал быть нужным.

Это до сих пор самый быстрый integer type вне зависимости от архитектуры. И зачастую size_t вместо int неоправдан: у Вас много контейнеров с 2e9+ элементами? Можно сколь угодно долго рассуждать о чистоте кода, но имхо это место где теория заметно расходится с практикой, но крайней мере в мире x86/x86-64.

надежнее в таких случаях сразу брать (u)int_max_t.

Из того что я слышу - на горизонте int128_t маячит. То что Вы задумали - довольно опасно.

НО КАК ТОГДА ПРОГРАММИРОВАТЬ ВАШ PDP-11?

Работал и писал код для нее …

Респект!

проще и надежнее в таких случаях сразу брать (u)int_max_t

Нафига? Если нужно «хоть сколько, не меньше 16 бит» - бери int, самый натуральный тип. В большинстве случаев согласен, плавающие типы - непродуманный бред.

int неизвестно какого размера мне перестал быть нужным

Я на С давно не писал, но полностью поддерживаю. Ну нах.

Шутка

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

Я ЩИТАЮ, что int в си больше не нужен ...

Гм.
И хорошо бы эшо кулаком по столу для большей убедительности.

Пока не буду говорить как подобные вопросы без особого труда решаются …

Владимир, правильно ли я понимаю, что уже в те далёкие годы, проводя время в компании подобного рода машин, Вы обнаружили что результат зависит от ДЛИНЫ, что во многом определило ваш дальнейший карьерный рост и сформировало как профессионала?

Чувствую толстый намёк на недостаточную длину.

Я могу привести контр пример. int на популярных 8 битных avr сделали 16 бит. Если на автомате писать for(int i = 0; i < 16; i += 1) то получится жирный тормозной код. Если вместо int взять правильный int8_fast_t то avr-gcc родит правильный код инкремента 1 байта.

С трудом понял к чему это «контр». Видимо к абзацу про потерю актуальности вариабельности int-а. Ну, я про 8 бит не догадался подумать вообще, и 16 то в экзотику записал. Да, в таком цикле наиболее переносимо-оптимизированным будет int8_fast. Хотя я тут ещё одну проблему int-а вспомнил - его бездумно суют как дефолтный целочисленный тип не только в плане разрядности, но ещё и в плане знаковости. Конкретно тут скорее всего лучше unsigned.

int на популярных 8 битных avr сделали 16 бит

Это можно было не уточнять) Радуйся что не 32 бита. 8-битовым он быть не мог никак, общепризнанный стандарт требует минимум 16 бит.

Владимир, правильно ли я понимаю, что уже в те далёкие годы, проводя время в компании подобного рода машин, Вы обнаружили что результат зависит от ДЛИНЫ, что во многом определило ваш дальнейший карьерный рост и сформировало как профессионала?

Ни чего не понял.
Это просто пример ШАБАШКИ.
В чем здесь профессионализм? …

Владимир

Чувствую толстый намёк на недостаточную длину.

Зато подгадить - СПЕЦ! …

Здесь и замера НЕ НУЖНО! 

Типичный ЛОР

Владимир

Я могу привести контр пример. int на популярных 8 битных avr сделали 16 бит. Если на автомате писать for(int i = 0; i < 16; i += 1) то получится жирный тормозной код.

А если сделать size_t i = 0; i < 16; ...?

Некоторое время продолжал использовать int и unsigned для всяких констант и вычисления во время компиляции пока не понял что проще и надежнее в таких случаях сразу брать (u)int_max_t.

Разрядность констант выше int-а может неожиданно испортить vararg. Потому как до int-а они так и так повышаются promotion-ом, и арифметика с int-константой тут ничего не поменяет, а intmax сделает аргумент intmax-ом. Это конечно не фатальная проблема (можно сделать тайпкаст или писать va_arg(arg,intmax_t) в функции), но об этом придётся везде помнить и засорять код лишними конструкциями.

Бывают 8-битные архитектуры с 16-битным линейным адресом (например 8080). Может быть, даже avr как раз такие.

Я себе кастомный printf сделал с удобными шаблонами, под это в том числе.

Ах ты ж хитрая жопа! :) Под шаблонами понимается «format specifiers»? Можешь показать спиочек с описаниями?

UPD. Мне периодически лениво мечтается забабахать на constexpr-ах и прочих template-ах парсинг format чтобы в compile time контролировать типы аргументов. Но учитывая какой это лютый гимор, оно так мечтами и останется. В растишке print – макрос; вот интересно, они там это сделали?

UPD. Мне периодически лениво мечтается забабахать на constexpr-ах и прочих template-ах парсинг format чтобы в compile time контролировать типы аргументов. Но учитывая какой это лютый гимор, оно так мечтами и останется.

Четырёхзвёздочный опять блистает)))

В fmtlib уже забабахано всё. 5 лет назад.

В fmtlib уже забабахано всё.

Сенькс, гляну.

чтобы не %d а %u8, %i32

Мегаплюс! А то эти форматы из stdint.h - убожище какое-то!

Ах ты ж хитрая жопа! :) Под шаблонами понимается «format specifiers»? Можешь показать спиочек с описаниями?

общий формат

%[flags][width][.precision][:maxwidth][mods]{type}

‘precision’ (%s and %S arguments) limits the number of bytes to lookup.
     Default: infinite.

     ‘precision’ (%b and %B arguments) specifies the number of bytes to print.
     Default: 1.

модификаторы

     hh      char
     h       short
     l       long
     ll      long long
     HH      int8
     H       int16
     L       int32
     LL      int64
     z       size_t

типы

     c       print a character
     C       print an escaped character
     s       print a null-terminated string
     S       print an escaped null-terminated string
     b       print an array of bytes
     B       print an escaped array of bytes
     d       print a signed integer value
     u       print an unsigned integer value
     o       print an unsigned integer value, octal
     x       print an unsigned integer value, hexadecimal 0-9a-f
     X       print an unsigned integer value, hexadecimal 0-9A-F
     p       print a pointer value, hexadecimal 0-9a-f, prefixed with ‘0x’;
             use ‘%010p’ to print in usual 0xNNNNNNNN form
     {tn}    special case, see below
     Note: NULL string printed as "(null)".

{tn}

     IP4     argument is a pointer to uint8[4] array which is printed in form
             %u.%u.%u.%u
     IP32    argument is an uint32 value which is converted to network byte
             order and printed like IP4
     MAC     argument is a pointer to uint8[6] array which is printed in form
             %02X:%02X:%02X:%02X:%02X:%02X
     ERR     argument is an int value which is printed in form %d (%s) with
             strerror(value) as %s argument
     XD:n    hexdump (like X) of "n" items. "n" may be "*" to get the value
             (as size_t) from arguments. Argument is a pointer to array of in‐
             tegers. Flags, width and mods are applied to each printed integer
             separately. Maxwidth applied to entire array. Value separator is
             space. There is no way to print in lowercase.

экранирование это \a \b \t \n \r \" \\ и \177 \000-\037 для остальных

Мне периодически лениво мечтается забабахать на constexpr-ах и прочих template-ах парсинг format чтобы в compile time контролировать типы аргументов. Но учитывая какой это лютый гимор, оно так мечтами и останется. В растишке print – макрос; вот интересно, они там это сделали?

gcc и так варнинги выдаёт на не тот формат

а в c++ есть iostream

Сенькс.

gcc и так варнинги выдаёт на не тот формат

Только на стандартные …printf(), но не для моих собственных кастомных функций (const char* format, …). Да и warning можно прощёлкать, если тип параметра поменять в другом файле.

а в c++ есть iostream

Оно реально тормозное.

Вроде для кастомных можно через attribute какое-то printf-like проверки добавить для прототипа функции. Но да, там только для тех кто ведёт себя как printf из стандартной библиотеки.

Вроде для кастомных можно через attribute какое-то printf-like проверки добавить для прототипа функции.

Хм, точняк. Но проблем при рефакторинге по площадям это не решеает. Отсюда и был мой старый вопрос.

UPD. Хм, таки решает. Ворнинг выплёвывается и clang, и gcc.

Кхм… какой от этого профит на десктопе?

Если у тебя нет требований по лимитам, и ты считаешь количество фруктов на дереве (ну то есть очевидно что их не будет больше чем 2^16), то вполне резонно использовать int либо unsigned int (либо другой тип, который отвечает размеру машинного слова)

В некоторых случаях это будет даже лучше чем short и char, самий тупняково-вопиющий вот тут: https://habr.com/ru/post/647165/

Ах ты ж хитрая жопа! :) Под шаблонами понимается «format specifiers»? Можешь показать спиочек с описаниями?

Вот если что сама библиотека (там не только печать а ещё много чего)

https://firk.cantconnect.ru/projects/fcl/

маны внутри тоже есть, конкретно формат в qlog.3

qprint то же но не для логов

Да.

Осознал

Лол.

Ты можешь себя конечно обманывать как хочешь, но твои точные типы просто дефайнятся к обычным char,short,int и так далее. Их размеры точно известны по формуле один не менее и больше предыдущего в рамках семейства платформ их размер железобетонно гарантирован и известен. Ты прав нет ничего плохого и часто очень хорошо когда ты указываешь точный тип тем самым точно зная какой размер тебе нужен для работы программы. Всякое по твоим словам странное и бредовое после прохода препроцессора будет на месте так что твои слова как раз и кажутся странными и бредовыми. Это всё равно что говорить - «тесто для больных на голову, эта дреснячая непонятная жижа вообще кому то нужна зачем её делать? Вот батон и буханка хлеба это норм, они по госту с ними всё ясно, а с тестом ничего не ясно что там получится из этой дрисни тягучей». Вот так читается твой эпос.

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

Не надо познать просвещение и в тайные сообщества вступать что-бы дефайны использовать или вообще свои типы делать. Просто используй что тебе необходимо и/или удобно. Откуда у тебя такой радикализм? =)

Сенькс! :)

Откуда у тебя такой радикализм?

Денди, ты? ☺ https://youtu.be/i_svkeWgsw8?t=134

Все кроме тебя поняли о чём автор написал.

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

Пардон за грубоватую форму изложения гы =)

Чем не устраивает fmtlib?

Stm8 еще