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