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