Чи належна практика покладатися на те, що заголовки будуть включені транзитивно?

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

Ось приклад Entity.hpp:

#include "RenderObject.hpp"
#include "Texture.hpp"

struct Entity {
    Texture texture;
    RenderObject render();
}

(Припустимо, що пряма декларація для RenderObjectне є варіантом.)

Тепер я знаю, що RenderObject.hppвключає Texture.hpp- я це знаю, тому що кожен RenderObjectмає свого Textureчлена. Тим НЕ менше, я явно включити Texture.hppв Entity.hpp, тому що я не впевнений , що це хороша ідея , щоб покладатися на нього включається в RenderObject.hpp.

Отже: це хороша практика чи ні?

Ви завжди повинні включати в цей файл усі заголовки, що визначають будь-які об’єкти, що використовуються у файлі .cpp, незалежно від того, що ви знаєте про те, що в цих файлах. У всіх файлах заголовків слід включити захисні пристрої, щоб переконатися, що включення заголовків кілька разів не має значення.

Причини:

• Це дає зрозуміти розробникам, які читають джерело саме те, що вимагає вихідний файл. Тут хтось, дивлячись на перші кілька рядків у файлі, може побачити, що ви маєте справу з Textureоб’єктами в цьому файлі.
• Це дозволяє уникнути проблем, коли відновлені заголовки викликають проблеми компіляції, коли вони більше не потребують конкретних заголовків. Наприклад, припустимо, ви усвідомлюєте, що RenderObject.hppнасправді не потрібна Texture.hppсама.

Наслідком є ​​те, що ви ніколи не повинні включати заголовок в інший заголовок, якщо це явно не потрібно в цьому файлі.

Загальне правило: включайте те, що ви використовуєте. Якщо ви використовуєте об'єкт безпосередньо, то додайте його файл заголовка безпосередньо. Якщо ви використовуєте об'єкт A, який використовує B, але ви самі не використовуєте B, включіть лише Ah

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

Мені цікаво, чи слід явно включати всі заголовки, що використовуються безпосередньо в певному файлі

Так.

Ніколи не знаєш, коли ці інші заголовки можуть змінитися. У світі має сенс включати в кожну одиницю перекладу заголовки, які ви знаєте, що потрібна одиниця перекладу.

У нас є захисні заголовки для того, щоб подвійне включення не було шкідливим.

Думки з цього приводу різняться, але я вважаю, що кожен файл (будь то вихідний файл c / cpp чи файл заголовка h / hpp) повинен бути здатний скласти або проаналізувати самостійно.

Таким чином, усі файли повинні #including будь-які і всі файли заголовків, які їм потрібні - не слід вважати, що один файл заголовка вже включений раніше.

Це справжній біль, якщо вам потрібно додати файл заголовка і виявити, що він використовує елемент, визначений в іншому місці, не включаючи його безпосередньо ... так що вам доведеться шукати (і, можливо, в кінцевому підсумку неправильний!)

З іншого боку, це не має значення (як правило), якщо ви #include файл, який вам не потрібен ...

В якості особистого стилю я впорядковую #include файли в алфавітному порядку, розбиті на системні та додаткові - це допомагає посилити повідомлення про "самодостатнє та повністю узгоджене".

Це залежить від того, чи є це перехідне включення необхідним (наприклад, базовим класом) або через деталі реалізації (приватний член).

Для уточнення, транзитивне включення необхідне, коли його видалити можна лише після першої зміни інтерфейсів, оголошених у проміжному заголовку. Оскільки це вже суттєва зміна, будь-який .cpp-файл, використовуючи його, потрібно перевірити.

Приклад: Ах включений Bh, який використовується C.cpp. Якщо Bh використовував Ah для деяких деталей реалізації, тоді C.cpp не повинен вважати, що Bh продовжуватиме це робити. Але якщо Bh використовує Ah для базового класу, тоді C.cpp може припустити, що Bh продовжить включати відповідні заголовки для своїх базових класів.

Тут ви бачите фактичну перевагу НЕ дублювання включень заголовків. Скажіть, що базовий клас, який використовує Bh, насправді не належить до Ah та перетворюється на Bh сам. Bh тепер окремий заголовок. Якщо C.cpp надмірно включав Ах, то тепер він включає непотрібний заголовок.

Може бути і інший випадок: у вас є Ah, Bh і ваш C.cpp, Bh включає Ah

тому в C.cpp можна писати

#include "B.h"
#include "A.h" // < this can be optional as B.h already has all the stuff in A.h

Тож якщо ви не напишете тут #include "Ах", що може статися? у вашому C.cpp використовуються як A, так і B (наприклад, клас). Пізніше ви змінили код C.cpp, видаліть пов’язані з B речі, але залишивши Bh там.

Якщо ви включите і Ah, і Bh, і зараз на цьому етапі інструменти, які виявляють непотрібні включення, можуть допомогти вам зазначити, що Bh включення більше не потрібне. Якщо ви включаєте лише Bh, як зазначено вище, інструментам / людині важко виявити непотрібне включення після зміни коду.

Я використовую подібний дещо інший підхід від запропонованих відповідей.

У заголовки завжди включайте просто мінімум, лише те, що потрібно для того, щоб компіляція пройшла. Використовуйте передову декларацію, де це можливо.

У вихідних файлах не так важливо, скільки ви включаєте. Мої вподобання все ще включають мінімум, щоб він пройшов.

Для невеликих проектів, включаючи заголовки тут і там, це не зміниться. Але для середніх та великих проектів це може стати проблемою. Навіть якщо для збирання використовується останнє обладнання, різниця може бути помітна. Причина полягає в тому, що компілятору ще належить відкрити включений заголовок і проаналізувати його. Отже, щоб оптимізувати збірку, застосуйте вищевказану техніку (включіть мінімальний мінімум та використовуйте оголошення вперед).

Хоча трохи застарілий, дизайн програмного забезпечення великих масштабів C ++ (Джон Лакос) пояснює все це детально.

Доброю практикою є не турбуватися про стратегію заголовка, поки вона складається.

Розділ заголовка вашого коду - це лише блок рядків, на який ніхто навіть не повинен дивитися, поки не з’явиться легко вирішена помилка компіляції. Я розумію прагнення до «правильного» стилю, але жоден спосіб насправді не можна охарактеризувати як правильний. Включення заголовка для кожного класу, швидше за все, спричинить дратівливі помилки компіляції на основі замовлень, але ці помилки компіляції також відображають проблеми, які ретельне кодування може усунути (хоча, певно, вони не варті часу на виправлення).

І так, ви будете мати ці проблеми порядку на основі , як тільки ви почнете отримувати в friendземлю.

Про проблему можна думати у двох випадках.

Випадок 1: Ви маєте невелику кількість занять, які взаємодіють між собою, скажімо, менше десятка. Ви регулярно додаєте, видаляєте та іншим чином змінюєте ці заголовки таким чином, що може впливати на їх залежність один від одного. Це той випадок, який пропонує ваш приклад коду.

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

Випадок 2: У вас десятки класів. Деякі класи представляють основу вашої програми, і перезапис їх заголовків змусить вас переписати / перекомпілювати велику кількість кодової бази. Інші класи використовують цю основу для досягнення справ. Це являє собою типовий бізнес-параметр. Заголовки розкинуті по каталогах, і ви не можете реально запам'ятати назви всього.

Рішення: На цьому етапі вам потрібно подумати про свої заняття в логічних групах і зібрати ті групи в заголовки, які не дозволять вам #include переробляти знову і знову. Це не лише робить життя простішим, але й необхідним кроком до використання попередньо складених заголовків .

Ти закінчишся #include заняття, які вам не потрібні, але кого це хвилює ?

У цьому випадку ваш код виглядатиме як ...

#include <Graphics.hpp>

struct Entity {
    Texture texture;
    RenderObject render();
}