Вперед, обо всем
Факт: предварительные декларации (типов классов) должны быть предпочтительнее, чем включает.
Есть ли обратная сторона в объявлении вперед всего в заголовке и включении этого заголовка? (Я предполагаю, что время компиляции не должно сильно увеличиться)
В больших кодовых базах предварительные объявления могут занимать много места на экране, и было бы здорово заменить их одним включением — однако не имеет смысла иметь заголовок прямого объявления для каждого заголовка с жду деклараций.
Кто-нибудь делал это или видел это раньше?
Решение
Я обычно делаю это в своих проектах. Но я разделил вперед декларации в modules, Например: gui, core и так далее. Это дает хороший баланс между перекомпиляцией из-за использования include в заголовках и между написанием предварительных объявлений вручную
Другие решения
Я думаю, что, не вдаваясь в крайности, вряд ли есть какие-либо недостатки, которые следует включать.
Мне лично было бы наплевать на пространство экрана. Это наверняка превосходит умножение времени сборки на 2–5–10. Раньше время сборки увеличивалось примерно на 2 часа… Некоторые дополнительные форварды могли исключить попадание одного и того же файла в тысячи раз.
В любом случае, вы не всегда можете использовать предварительную декларацию для всего. Если вы что-то подклассифицируете, у вас должно быть определение класса, и это может означать включение. Все в порядке.
Единственное, что вы можете сделать, чтобы удалить зависимости, это деинлайн-код в заголовочных файлах. Удостоверьтесь, что интерфейсы работают вверх, а реализации вниз (см. Стандарты кодирования C ++ Sutter и Alexandrescu). То есть предпочитайте, чтобы ваши общедоступные API были абстрактными интерфейсами, если это возможно. Если вы можете сделать это, то сумма, которую вы должны включить или переслать, может быть сведена к минимуму.
О, а также не помещайте сотни функций и классов в один заголовочный файл, так что это 8000 строк. Никто не может читать / понимать такие файлы.
Одним из основных преимуществ использования предварительного объявления вместо включений является то, что вам не нужно перекомпилировать столько исходных файлов при каждом изменении файла заголовка, поскольку этот файл заголовка будет включен только там, где это действительно необходимо.
Ваш подход может уменьшить это преимущество, а в некоторых случаях даже усугубить его: каждый раз, когда вы добавляете или удаляете класс где-то, вам нужно будет изменить глобальный заголовочный файл, который содержит предварительные объявления. И тогда вам нужно будет перекомпилировать каждый исходный файл в вашей кодовой базе, включая те, которые не используют добавленный класс.
Тем не менее, поскольку классы, вероятно, добавляются не слишком часто, возможно, это не так уж и плохо.