POV (14.04.2025 12:28, просмотров: 231) ответил il-2 на Использование в заголовочных файлах Си заградительных макросов:-
- Это как раз и есть нехороший вариант, хотя и рабочий. В
заголовочнике должно быть все необходимое. - il-2(14.04.2025 12:36)
- Чем меньше инклюдов в заголовочнике - тем лучше. Только то, что
нужно для объявления своих структур и аргументов функций (скажем,
stdint.h). - Eddy_Em(14.04.2025 17:08)
- Присоединяюсь! Отлить в золоте! - Nikolaj(15.04.2025 04:41)
- Люто плюсую! - Nikolay_Po(14.04.2025 18:41)
- Нет. Согласен с предыдущим оратором POV. Суй всё необходимое в реализацию - в файл *.c. В заголовочном
только то, что необходимо для пользования функционалом модуля,
того, что в .c файле. - Nikolay_Po(14.04.2025 13:44)
- я считаю, что инклуд должен компилироваться без ошибок. Но каждый
дрочит, как он хочет. - abivan(14.04.2025 15:29)
- Инклюд вообще не должен компилироваться. В нём не должно быть
определений. Только объявления. Можно, конечно, всю библиотеку
зафигачить в один .h. Но это совсем другое. - Nikolay_Po(14.04.2025 18:42)
- Есть header-only библиотеки, но да, в отдельном сишном файле нужно
объявить макрос инициализации. А еще можно true-inline функции в
header'ы складывать.. - Eddy_Em(14.04.2025 22:15)
- inline - это для маньяков. И для маньяков давно придумали получше:
LTO. - SciFi(14.04.2025 22:16)
- С LTO иногда непонятные глюки при сборке получаются. Но да, штука
очень полезная. Я даже под STM32 в release-сборке -flto добавляю. - Eddy_Em(14.04.2025 23:23)
- Дорос. Глюки при сборке с ЛТО - повод рефакторить код. - Nikolay_Po(14.04.2025 23:42)
- Это да: свою утилиту для работы с ПЗС/КМОП-светоприемниками я
добрую неделю "рефакторил" после того, как решил LTO добавить. Eddy_Em(179 знак., 15.04.2025 08:37)
- Был, например, случай, когда сломался код для SPI флешки.
Оказалось, нужно было добавить явную задержку на Chip Select. Эта
задержка получалась сама собой, пока LTO не было включено. Но
отлаживать такие вещи сложно, конечно. Дизассемблер и исходник
могут сильно разъехаться. - SciFi(15.04.2025 09:27)
- Хмм... Мой код не ломается. Я тщательно изучаю документы и проверяю сигналы осциллографом. Потом добавляю в код задержку принудительно, чтобы при максимальной скорости исполнения, необходимые интервалы были гарантированно выдержаны. Иногда ставлю задержки даже там, где код не успевает и так. Но ставлю. Как раз чтобы не получить неопределённого поведения аппаратуры при перекомпиляции другим компилятором с другими параметрами. - Nikolay_Po(15.04.2025 09:35)
- Был, например, случай, когда сломался код для SPI флешки.
Оказалось, нужно было добавить явную задержку на Chip Select. Эта
задержка получалась сама собой, пока LTO не было включено. Но
отлаживать такие вещи сложно, конечно. Дизассемблер и исходник
могут сильно разъехаться. - SciFi(15.04.2025 09:27)
- Это да: свою утилиту для работы с ПЗС/КМОП-светоприемниками я
добрую неделю "рефакторил" после того, как решил LTO добавить. Eddy_Em(179 знак., 15.04.2025 08:37)
- Дорос. Глюки при сборке с ЛТО - повод рефакторить код. - Nikolay_Po(14.04.2025 23:42)
- С LTO иногда непонятные глюки при сборке получаются. Но да, штука
очень полезная. Я даже под STM32 в release-сборке -flto добавляю. - Eddy_Em(14.04.2025 23:23)
- inline - это для маньяков. И для маньяков давно придумали получше:
LTO. - SciFi(14.04.2025 22:16)
- У меня нет определений в инклудах. Но инклуды все самодостаточны, и
могут быть скомпилированы без сообщений о том, что какой то тип,
который объявлен в другом инклуде не объявлен. - abivan(14.04.2025 19:16)
- Есть такой вариант. Да, хорошо делать так, чтобы для заявленного
библиотекой функционала, достаточно было включить её заголовок, без
ожиданий, что пользователь включит недостающее сам. Nikolay_Po(875 знак., 14.04.2025 23:52)
- Если пользователь не обращается к элементам структуры напрямую, только через функции-методы, то предоставлять поля структуры в хедере не обязательно. Только имя для связывания. Это позволяет спрятать все артефакты внешней либы от пользователя и соответственно не инклудить её хедеры. Без всяких приведений типа. =AlexD=(278 знак., 15.04.2025 09:46)
- Есть такой вариант. Да, хорошо делать так, чтобы для заявленного
библиотекой функционала, достаточно было включить её заголовок, без
ожиданий, что пользователь включит недостающее сам. Nikolay_Po(875 знак., 14.04.2025 23:52)
- Есть header-only библиотеки, но да, в отдельном сишном файле нужно
объявить макрос инициализации. А еще можно true-inline функции в
header'ы складывать.. - Eddy_Em(14.04.2025 22:15)
- Инклюд вообще не должен компилироваться. В нём не должно быть
определений. Только объявления. Можно, конечно, всю библиотеку
зафигачить в один .h. Но это совсем другое. - Nikolay_Po(14.04.2025 18:42)
- я считаю, что инклуд должен компилироваться без ошибок. Но каждый
дрочит, как он хочет. - abivan(14.04.2025 15:29)
- Нет. В заголовочнике только определения, которые ты хочешь кому-то
предоставить. Без этого хедер и нахер не нужен. - POV(14.04.2025 12:49)
- У нас уже разночтения начались. Все это верно. В хедере должен быть
только внешний интерфейс. В т.ч. и другие необходимые хедеры. Вот с
этим то и начинаются проблемы. il-2(225 знак., 14.04.2025 14:36)
- Не редко внешний интерфейс использует типы, прописанные в других хедерах. Тогда удобен инклуд в инклуде и не требуется соблюдать порядок инклудов в сишнике. - AlexBi(14.04.2025 15:34)
- Разбиение на мелкие сущности хорошо, перестановка - плохо. - Andreas(14.04.2025 14:39)
- У нас уже разночтения начались. Все это верно. В хедере должен быть
только внешний интерфейс. В т.ч. и другие необходимые хедеры. Вот с
этим то и начинаются проблемы. il-2(225 знак., 14.04.2025 14:36)
- Чем меньше инклюдов в заголовочнике - тем лучше. Только то, что
нужно для объявления своих структур и аргументов функций (скажем,
stdint.h). - Eddy_Em(14.04.2025 17:08)
- Это как раз и есть нехороший вариант, хотя и рабочий. В
заголовочнике должно быть все необходимое. - il-2(14.04.2025 12:36)