include в хидере - всё таки это доро или зло?, Есть противоположные мнения, хочется понять их Опции

[Cosmojam]

Речь идёт про Си. Си++ не трогаем, хотя догадываюсь что аргументы там те же.

Существует мнение что писать в .h все необходимые инклюды - это плохо. Единственное подтверждение почему это плохо что мне удалось найти - время компиляции увеличивается. Многократные инклюды одного хидера лечатся очень просто с помощью ifndef/define и как аргумент не рассматриваются т.к. без защиты от множественных инклюдов в любом проекте где один хидер используется более чем в 1 .c файле будут проблемы.

Мой аргумент почему это стоит делать: Хидер - это заголовок модуля, определяющий его публичный интерфейс. Логично расположить в нём всё необходимое для работы модуля, а в .с файле инклюдить только один этот заголовок т.о. отделив реализацию от интерфейса. Улучшается наглядность т.к. сразу в хидере видно зависимости от других модулей.
Погуглив можно найти мнение со ссылкой на NASA C coding standard где написано

(4)
The unit header file shall contain #include statements for all other headers required by the unit
header. This lets clients use a unit by including a single header file.

Так как же "правильнее"? NASA не дураки ведь. Так почему существуют противоположные мнения?

[_Pasha]

Инклюды в хедере - вне добра и зла и их применение диктуется необходимостью минимизации зависимостей между единицами трансляции.

[AlexandrY]

Инклюды в хедере - вне добра и зла и их применение диктуется необходимостью минимизации зависимостей между единицами трансляции.

Загадочно сказано.
О каких зависимостях идет речь?
Допустим весь код уже написан и надо скомпоновать хидеры. Как мы будем тут "минимизировать зависимости"?

[Сергей Борщ]

Загадочно сказано.

Нормально вполне. Подключение заголовочного файла должно тянуть все, что необходимо для этого заголовочного файла и ничего более.

Допустим весь код уже написан и надо скомпоновать хидеры.

А вот это как? Как код может быть написан без заголовочных файлов? Как же он тестировался?

[AlexandrY]

Нормально вполне. Подключение заголовочного файла должно тянуть все, что необходимо для этого заголовочного файла и ничего более.

А вот это как? Как код может быть написан без заголовочных файлов? Как же он тестировался?

Я вообще-то обсуждаю только крупные проекты.

Тогда скажем взяв какой-нибудь файл размеров с пару сотен килобайт даже если его сами написали все равно не сможете по памяти сказать, что ему необходимо из заголовочных файлов.
Неминуемо захочется создать один .h файл куда засунуть все что ни попадя, лишь бы после десятка минут компиляции, в самом конце причем, не узнать о недостающих объявлениях.

Код не пишется, а компонуется.
Пишется там десяток файлов целевого приложения, меньше процента от общего числа уже созданных исходников.
Хорошая компоновка(не написание!) хидеров значительно сокращает время отладки (которая сопровождается постоянными перекомпиляциями и рефакторингом).

Кстати еще есть такая тема как приватные и публичные хидеры. Не раз такое обнаруживал в разных GUI, FS и проч. Как правило это деление приходится нарушать в процессе портирования. Вот тут просто раздолье для маневров с хидерами.

Но вот про зависимости я не понял.