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 не дураки ведь. Так почему существуют противоположные мнения?

[AlexandrY]

Существует мнение что писать в .h все необходимые инклюды - это плохо.
Единственное подтверждение почему это плохо что мне удалось найти - время компиляции увеличивается...

В мелких проектах (десятки файлов) не имеет никакого значения.

Но в в больших проектах (сотни и тысячи файлов) структура хидеров самая большая проблема.
Тут никакие мнения не работают, все делается по обстановке.

Хидеры разных сторонних модулей могут содержать повторяющиеся имена (стабильно все переопределяют TRUE, FALSE, ERROR, OK и т.п. ), т.е. их просто невозможно разместить в одном общем хидере.
Часто переопределяются стандартные C-и функции, которые в основном приложении может переопределять нежелательно.
Сторонние модули уже могут идти со своей распределенной структурой хидеров и собрать из них один общий не представляется возможным.
В больших проектах также стоит отделять хидеры отлаженных сторонних модулей как например RTOS, GUI, FS от хидеров приложения.
Поскольку приложение постоянно рефакторится и любое изменение в приложение приводит к перекомпиляции всех модулей в случае общего хидера.
И т.д.
Вообщем все определяет технология.

[halfdoom]

В мелких проектах (десятки файлов) не имеет никакого значения.

Но в в больших проектах (сотни и тысячи файлов) структура хидеров самая большая проблема.
Тут никакие мнения не работают, все делается по обстановке.

+1. Очень простой пример: есть большой модуль, с парой десятков интерфейсных функций. Среди них есть одна, редко используемая функция, которая получает в качестве аргумента указатель на структуру foo: "void fn22(struct foo *);". Ради компилируемости, можно добавить include "foo.h", но если этот foo.h тянет за собой еще десяток инклюдов, то лучше просто объявить структуру как "struct foo;" и возложить необходимость включения foo.h на пользователя, которому эта структура понадобится.

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

[demiurg_spb]

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