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

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

A>>Наличие плавающего размера — это одна из самых уродливых черт С/С++. Ты хоть раз извлёк из этого пользу? Твою программу перенесли на другую платформу без изменения одной строчки кода, и у юзеров ВДРУГ появился доступ к расширенному диапазону? Так никто не пишет лет тридцать уже. Все типы должны иметь однозначно и строго заданный размер, точка
A>>Если у тебя все типы имеют размер, что делать в редких ситуациях, когда тебе нужно явно указать самый распространённый целый знаковый? Некоторые заставляют писать i32, некоторые дают алиас int. Последнее предпочтительнее, глаза цифрами не мозолить

N>Знаешь, в чём твоя ошибка? Ты путаешь _размер_ представления где-то в памяти и _множество значений_, а путаешь ты потому, что слишком заточился на метод мышления C, где они насильно (каламбур) отождествлены.

N>Если бы ты больше вспоминал языки чуть более высокого уровня (а не портабельный ассемблер, и неважно, с классами или нет), то ты бы вспоминал паскалевские (и потомков) определения типа "type temperature = new range -50...+80" и для этого было бы неважно, куда будет тебе это число помещать компилятор — в AL, AX, EAX или RAX, со смещением (перемасштабировав на 0...130) или нет, и так далее. Реально пофиг.
N>Должно было быть важно, как эти типы передаются вовне, как печатаются в I/O, влезают ли в конкретное гнездо в 8 бит, которое у тебя в структуре (явно помеченной как склад битовых полей! иначе неважно), и чтобы, если бы ты запросил (или по умолчанию) выход за границы вызывал бы исключение (ставил флаг ошибки, etc.), а иначе — работал бы тоже как-то иначе.

N>В call convention ABI этого много есть, например, в таком виде: "целочисленный параметр должен занимать целый регистр и знаково расширен до полной ширины даже если он беззнаковый" (пример для RISC-V). Это уже дело компилятора, линкера и прочих, а не твоё.

N>И только для согласования с конкретными тараканами нижнего уровня тебе реально нужен тип данных вроде "int_native". Но ты можешь описывать конкретный тип как "signed(10)" вместо "range -512...511", если ты думаешь в мышлении битовых полей. Нивапрос. Главное — следить за _использованием_ и _операциями_, а также требовать контроля множества значений, где важно.

N>А вот когда ты начинаешь думать вместо "range -50...+80" в понятиях типа int8_t, ты берёшь на себя лишнюю работу за компилятор и при этом мешаешь компилятору делать правильные выводы о твоих намерениях.

N>В 70-е подходы с правильной типизацией в стиле Pascal/Modula/Ada были преждевременными. Сейчас они, наоборот, безумно отсталые, смотреть надо вперёд. А не назад, как в C.

А мне зачем эти абстракции нужны? Чтобы они протекли? Чтобы поиметь лишний геморрой при сопряжении с каким-нибудь LPARAM, из которых (сопряжений) реальная работа разработчика и состоит чуть менее, чем полностью? (Ничего себе, "И только для согласования с конкретными тараканами нижнего уровня"!) Или чтобы нельзя было прикинуть размер файла с данными?

Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия? Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен. Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов. Тем и отличается практично мыслящий разраб от архитектурного космонавта. (Любезность за любезность ).

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