Комментарии 33
Подробнее можно почитать тут: A Resource Compiler with CMake and Standard C++
Решение интересное, но, кажется, что некоторых кейсах это проще сделать через xxd.
xxd --include filename
выведет что-то вроде:
unsigned char filename[]={ 0x48, ...};
unsigned int filename_len = 123;
Для небольших файлов. Если файл несколько Мб, то зачем лишний раз напрягать компилятор? (И хранить сам файл в двух вариантах: оригинал и с-массив.) Лучше сделать через objcopy
, как замечено в комментарии ниже. Да и xdd нет под виндой из коробки.
Особенно это хорошо для эмбеддеда, потому что он не дописывает const. В результате полмегабайтный файл пытается влезть в оперативку. И руками этот const приходится дописывать
Я пару раз делал подключал бинарные файлы через objcopy --input-target binary
Быстрый гуглинг так же предлагает https://github.com/graphitemaster/incbin.
А вообще — ждем принятия соответствующего Proposal и облизываемся на растовый std::include_bytes
$%.o: $src/example.img
mkdir -p $(builddir)
arm-none-eabi-ld -r -b binary -o $@ $<
arm-none-eabi-objcopy --rename-section .data=.rodata,alloc,load,readonly,data,contents $@ $@
extern const char *data_start = asm("_binary_src_fatexample_img_start");
extern const char* data_end = asm("_binary_src_fatexample_img_end");
Насчёт микроконтроллеров: во время работы контроллера данные хранятся на flash или целиком загружаются в RAM? У меня почему-то получалось, что при объявлении в коде статического массива с данными на stm32 тот грузился целиком в оперативку и это меня не очень устраивало.
Для разных микроконтроллеров по-разному. Для stm32 вам ответили, а, например, для avr надо кроме этого добавлять к определению массива attribute(progmem) или что-то ещё, смотря какой компилятор.
Секция .rodata у ARM Cortex M, как правило, располагается во флеше, а .data — в оперативке. Но если у вас что-то чуть сложнее микроконтроллера, то правила линковки и загрузки могут быть уже другими (к примеру, если программа грузится не с eXecute In Place-накопителя)
А для js/ts есть не велосипедный способ сделать такое? Интересует вкомпиляция (например) картинки в бинарном виде. В golang завезли embed на туже тему.
Кстати говоря, я еще год назад рассказывал[1], что в следующем стандарте препроцессор C будет, вероятно, поддерживать такое включение директивой embed [2].
[1] Статья про преполагаемые нововведения
[2] Последняя итерация предложения в комитете
Эти методы сами экранирует 'опасные' символы, делая очень эффективную строку (с оговорками для не латинских символов и неправильного выбора кодировки), совместимую с C-языками.
p.s. objcopy добавляет данные в obj файл
Главная проблема перечисленных вами функций — в том, что они работают с юникодовыми строками, т.е. последовательностями символов — в то время как бинарные данные являются последовательностью байт. И не любую последовательность байт можно интерпретировать как последовательность символов для кодирования.
Вторая проблема такого кодирования — в том, что оно ничуть не эффективно, формат \uNNNN
требует шести байт для представления двух.
с оговорками для не латинских символов
Таких "символов" в бинарных данных будет половина.
PS Вообще фича вставки бинарников весьма очевидна, странно что еще в Си ее не реализовали. В языке D кстати такая возможность добавлена официально.
Я использую objcopy как некое кроссплатформенное решение, но нужно установить objcopy на винду.
Про очевидность :) Для вас — очевидно, для меня — очевидно, но я поспрашивал знакомых с/с++ разработчиков, оказываается для многих совершенно не очевидно :) следуют вопросы: а зачем? а почему в файлах не устраивает? и тп :)
И я тоже не понимаю почему возможность добавлять бинарные данные в .data и в .rdata секции не добавлена в С. Хотя может считали избыточным, что есть другие тулы для этого.
del
По крайней мере, в с+11 всякие экзотические строки можно так задавать:
const auto str =
R"(
first line blabla #~\/&$
second line blabla
)";
Мы у себя именно так и сделали.
Тоже смотрели на ресурсы и xxd.
Но ресурсы — это всё же не от языка, а внешнее (нет желания напороться на формат экзешников, где они не предусмотрены). xxd — да, но с "сырыми" литералами он тоже выглядит излишне (к тому же требует установки).
В итоге "навелосипедили" скрипт для cmake, который нужные файлы кодирует в один или несколько литералов. которые потом в основной сборке подключаются через #include.
(в один или несколько — потому что эти самые "экзотические строки" всё же имеют ограничения. Под виндой — 65к на литерал).
А если нужно посчитать CRC всей секции данных (а то и всех секций сразу) и положить его в бинарник, то кроме как посчитать CRC в python-скрипте и пропатчить бинарник — ничего не придумывается.
ld -r -b binary file.txt -o file.o
а в остальных файлах можно использовать
extern char _binary_file_txt_end[];
extern char _binary_file_txt_start[];
Как подключить содержимое любых файлов для использования в коде C / C++