> Ну тебе же не западло целый 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. Это кстати не я придумал, но идею ессно упер :)
