> Проблемав в том что в C строго - понятие растяжимое из за
> лени авторов стандарта. Есть такое.
Но _главное_ назначение Си - писать системный код. То что на нем можно написать любую прикладную программу, хоть это и не будет продуктивным трудом, это побочный эффект.
> Скажем никогда не видел .. char 16 битный? это еще и практикуют.
Видел. Но это же и не платформа для портирования ядра Linux.
И тем более не повод в исходнике предполагающем портирование не переопределить типы. Писать в исходнике именно char, но использовать его с жесткой привязкой к платформе - верный путь остаться без премиии. ;)
> А как вам 16-битные int?
Те же грабли. Том 2й.
И сейчас любилели 32х битных указателей дописывают том 3й.
Хотя ещё в 90х, даже на русском было написано, что нельзя полагаться на размеры системнозависимых типов. И как правильно писать переносимый между платформамии код.
> А теперь коронный номер: попробуй это корректно по коммуникационному протоколу другим системам
> передать, во. В вот таком виде. И чтоб твой код в
> вон тех допущениях не помер, а на другой стороне линка поняли
> что ты передал и однозначно интерпретировали это. Что, все еще хочется
> такими типами оперировать? :)
Элементарно. Достаточно писать в правильном стиле.
Ну как пример, я пишу сейчас библиотеки для DLMS/COSEM. Там и протоколы, и базы, преобразования их одного в другое.
А собираеются проекты под STM32, ESP32, китайские Vango, Windows 64bit, Linux ARM, Mac M1 и Mac PowerPC. Распберри и PowerPc скорее для спортивного интереса, но завелось же.
А в этом случае еще помимо каких то типов, разных ABI, еще и разные ОС, и их отсутствие.
И не поверите, исходники не обложены кучами ifdef'oв. А работа на одной платформе с Eeprom, на другой с SDкартой, а следующей файлом( а в разных ОС и это по своему), или в одной платформе UART, а в другой сокеты, также нужны таймеры, миллисекундный источник времени, вывод то на spi-экранчик, а то дисплей, или интерфейс для Алисы, или ничего, и так далее.
Кратко, ОС специфичные функции вынесены в отдельные файлы, интерфейсы взаимодействия с пользователем - отдельные, и нативные функции вызываются только через функции-обертки или заглушки, что б и исходнике их не было, так исключается привязка и именам функций и структур ОС, и основная часть исходников пересобирается без правки, даже при переезде на очередную платформу, и не нужно искать сюрпризы в уже написанном коде.
Очевидно, что платформозависимые типы в исходниках не используются.
А вот как работать с разным ABI не погрязнув и в ifdef'ах? Особенно в протоколах и форматах обмена. Правильнее хранить локальные данные в нативных форматах, в для тех же протоколов парсить и генерировать данные, но не соваться переставлять байты и считать биты "вручную". Если хочется переоптимизированного исходника, что для "протоколов уже излишне", но если надо, то надежнее написать генератор исходника, работающий по шаблонным поавилам, а не писать оптимизированные хаки на каждый чих.
Если обменяться идеями, прошу в личку.
> другое если чудит вместо него компилер и implementation specific behavior
У плохого повара, всегда кастрлька виновата, в том числе и когда дело именно в ней. И этим злоупотребляют, делая её виноватой во всех бедах до того, как разобраться.
> не знает что он - чудак.
Если бы он работал с электроникой, то распаяв и перенапаяв прибор как нибудь, он и интуитивно точно догадался бы, что работать не будет. (а когда точно должно работать, но не работает, это другое)
Но почему то в программировании принято верить что написанное спустя рукава ну хоть как нибудь да заработает.
Системный язык хоть и оперирует отдельными байтами и битами, но системный программист должен не только представлять продукт целиком, но и то как он взаимодействует с другими системами, а для этого надо в какой то мере знать и другие платформы. Часто нужна математика, хотя бы на уровне первого курса.
Тут уж если полез в системное программирование, то сем себе яму и вырыл. Если язык небезопасный, и слишком много ньюансов приходится держать в голове, стоит задуматься о переходе на другой язык.
