> Ну тебе же не западло целый ico-файл со всеми хедерами втащить?

Классические ico файлы и их хидеры - весьма мелкие, и довольно просты в парсинге. Особенно если договориться о каких-то constraints. Ибо дедалось в эпоху царя гороха еще, когда компы были крупнее и дохлее. Самое что надо для МК с ограниченными ресурсами, стало быть.

>>Прекрасно - и тогда бинарный ресурс в фирмвару мы инклюдим, например, как?!
> Если у вас хилый контроллер, и вам надо бинарные ресурсы в прошивку
> вкомпиливать, то вы делаете всё неправильно.

ORLY? То-есть например фонт чтобы немного порисовать на небольшом LCD или OLED мне не надо? И да, он может быть диагональю менее дюйма, даже чернобелый, на i2c или spi, так что это своротит даже самый паршивый МК. Но текст же на массив пикселей надо как-то отрендерить, мистер эксперт?!

> Либо крестик снимите, либо трусы наденьте.

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

> Ресурсы в виде готовых бинарных файлов нужны ровно в одном
> случае — у вас там веб-сервер сидит и их отдаёт.

Булшит бинго. Скажем если к МК прицеплен небольшой LCD или OLED - сразу начинает хотеться как минимум фонт почему-то. А иногда и ряд иных вещей. А вот зачем мне ФС и код ее парсинга чтобы пару строчек на OLED микроскопический порисовать?!

> Что исключает хилый контроллер и уже требует файлосистему.

В каком месте желание вывести пару строк статуса на мизерный OLED размером сантиметр на два "требует файловую систему"?! Вы там того?

> Которая может быть очень простой и виртуальньй:

А нафиг мне ФС в вон том кейсе? И прочие "файловые операции". Оно в сумме весить будет - как пять фонтов для вон того.

> 1. компилятор ресурсов берёт ресурсы по именам,

Вау, то-есть мне еще и это надо кодить и/или наруливать в билде фирмвари? Вместо 1 строки инклюда?

> и генерит perfect hash function. Причём constexpr.

Ага, вместо 1 строки кода то...

> 2. он же генерит файл с ресурсами, просто таблица.

А зачем мне вообще абстракция файлов в той штуке вперлась? Там фонт вообще - один на всю систему, hardwired, и ЭТО своротит - блин, даже PIC и прочий AVR. Или там какой cortex M0 самый копеечный, да даже вон тот RISCV за 0.2 бакса. Но вот куда там ФС то?...

> 3. в коде ресурсы идут по путям, но компилятор их прямо при
> компиляции хэширует и прямо при компиляции выполняет lookup в таблице. C++23.

Себе его оставьте, имхо. У C++ все намного сложнее с сетапом арены и ее предсказуемостью, и я таки предпочитаю си в простых фирмварах с повышенными требованиями к надежности и предсказуемости. Это никак не исключает желание отрисовать до кучи допустим статус на мелкий экранчик типа oled или lcd на какомнить i2c или spi. И вот там инклюдануть что-то типа фонта вот так - очудобно!

> 4. а если надо в динамике - то код для функции компилятор засунет.

F...k overengineering!

> её инклюдить, причём как consexpr, а не как байты копировать.

Мне инклюд объекта как "const" вполне нормуль. Хотя такие вещи по хорошему лучше runtime калиброваками все же делать. На случай уплывания параметров или замены термопары.

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

Предпочитаю иметь явный контроль над данным аспектом для информированного принятия решения как оно мне надо, а не то что там компилятор себе удумает по рандому. В фирмвари я предпочитаю плотный контроль layout результата и что у меня где. Например чтобы при случае допустим runtime калибровки уметь. Даже возможно отдельным модулем - сохраняющим их в well defined area. Это кстати не я придумал, но идею ессно упер :)