Если воспользоваться стандартными тулами из поставки какого-нибудь gcc, то можно и по имени структуры в которую упакованы ваши константы, пропатчить эльф, без геммора с адресами. Получится более гибкий путь.
Что такое непубличные методы в сишниках? Те которые не должны торчать наружу из этого модуля? Так почему бы их не сделать статическими и не высовывать прототипы в хедер?
Добавлю еще, что все эти системные макросы в хедерах микроконтроллеров не просто так макросами сделаны. Они пишутся не руками, получаются автоматически из RTL.
Это если вам во время работы нужны все эти значения, а если это лишь для инита, то всё это нет смысла рассчитывать и хранить, гораздо удобнее взять макрос и не париться.
Так вот если вы пишите в каком-то другом хедере прототип функции где используется указатель на этот тип
void func(types_truct_s * arg);
Можно не инклудить весь первый большой хедер в этом, а инклудить его только в сишном файле. А сам тип описать вот так
typedef struct types_truct_s types_truct_s;
Что мы имеем в такой компоновке: в хедерах минимум инклудов, все инклуды в сишниках. Благодаря этому если есть модуль который зависит от второго файла, но не использует эту функцию, он не будет инклудить первый хедер со структурой.
Стоит отметить, что это не сработает, если будет требоваться передать или вернуть структуру по значению. Суть в том, что компилятор когда пробегается по файлу видит что есть такой тип и он где-то определен. Это условно похоже на то как работают описания и определения функций (прототипы и тела)
Главный принцип: меньше инклудов в хедерах. При таком подходе не будет каскадной зависимости одного модуля от тысячи других. Заодно ускорится сборка проекта.
objcopy --update-section .name=newdata.bin fmw.elfПодставьте свои имена
Если воспользоваться стандартными тулами из поставки какого-нибудь gcc, то можно и по имени структуры в которую упакованы ваши константы, пропатчить эльф, без геммора с адресами. Получится более гибкий путь.
Поздравляю вы научились пользоваться линкером и атрибутом для указания секций
В скриптах линкера поменяйте и всё
Зато загрузчик с лишним CLI и запуском тестов очень необходим. Где-то вы перегибаете.
Какие сложности в реентерабельности?
Да ладно вам, будто в плюсовом мире меньше идиотизма.
Именно это и имел ввиду. Да и в принципе называть любую функцию хуком
Тот случай когда реактер добрался до вью...
Для продакшена возможно лучшим будут пересобрать образ и избавиться от ненужных файлов в виде исходников, девзависимостей и др.
RISC-V RV32I стандарт или всё-таки спецификация?
Ну вы конечно сравнили фрикад с солидом и кикад с альтмумом, даже смешно.
Чем весьма популярный OpenXML хуже этой библиотеки?
Да-да, а что делать если массив приходит извне?
Или вам нужно работать с ним и в многомерном представлении и в одномерном.
С точки зрения языка все верно и противоречий со здравым смыслом нет. Ничего удивительного.
Хочешь итерироваться как по одномерному - сделай кастование к одномерному массиву или просто к указателю.
Понял о чем вы, да, принцип похож, но цель другая
Скорее всего это про другое.
Что такое непубличные методы в сишниках? Те которые не должны торчать наружу из этого модуля? Так почему бы их не сделать статическими и не высовывать прототипы в хедер?
Хорошо и адекватно написанный код при любом уровне оптимизации работает предсказуемо и одинаково.
А вот если при О0 всё хорошо, но при каком-нибудь Оz падает, говорит о кривости кода и того кто это писал.
Добавлю еще, что все эти системные макросы в хедерах микроконтроллеров не просто так макросами сделаны. Они пишутся не руками, получаются автоматически из RTL.
Это если вам во время работы нужны все эти значения, а если это лишь для инита, то всё это нет смысла рассчитывать и хранить, гораздо удобнее взять макрос и не париться.
У вас есть тип в одном хедере
Так вот если вы пишите в каком-то другом хедере прототип функции где используется указатель на этот тип
Можно не инклудить весь первый большой хедер в этом, а инклудить его только в сишном файле. А сам тип описать вот так
Что мы имеем в такой компоновке: в хедерах минимум инклудов, все инклуды в сишниках. Благодаря этому если есть модуль который зависит от второго файла, но не использует эту функцию, он не будет инклудить первый хедер со структурой.
Стоит отметить, что это не сработает, если будет требоваться передать или вернуть структуру по значению. Суть в том, что компилятор когда пробегается по файлу видит что есть такой тип и он где-то определен. Это условно похоже на то как работают описания и определения функций (прототипы и тела)
Главный принцип: меньше инклудов в хедерах. При таком подходе не будет каскадной зависимости одного модуля от тысячи других. Заодно ускорится сборка проекта.