Що повинно бути, а що не повинно бути у файлі заголовка? [зачинено]

Які речі абсолютно ніколи не повинні включатись у файл заголовка?

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

Які функції повинні входити у файл заголовка?
Які функції не повинні?

Що поставити в заголовки:

• Мінімальний набір #includeдиректив, необхідних для того, щоб зробити заголовок комбінованим, коли заголовок включений у якийсь вихідний файл.
• Визначення символів препроцесора речей, які мають бути спільними та які можна виконати лише за допомогою препроцесора. Навіть у С символи препроцесора найкраще звести до мінімуму.
• Передавання декларацій структур, які необхідні для визначення визначень структури, прототипів функцій та декларацій глобальних змінних в тілі заголовка, складеним.
• Визначення структур даних та перерахувань, які спільно використовуються між декількома вихідними файлами.
• Декларації для функцій та змінних, визначення яких буде видно лінкеру.
• Вбудовані визначення функцій, але будьте уважні.

Що не належить до заголовка:

• Безкоштовні #includeдирективи. Ці безоплатно включають причину перекомпіляції речей, які не потрібно перекомпілювати, а часом можуть зробити так, що система не може компілювати. Не #includeвикористовуйте файл у заголовку, якщо сам заголовок не потребує іншого файла заголовка.
• Препроцесорні символи, наміри яких могли бути виконані якимсь механізмом, будь-яким механізмом, крім препроцесора.
• Багато та багато визначень структури. Розділіть їх на окремі заголовки.
• Вбудовані визначення функцій, які потребують додаткової #include, які можуть бути змінені або занадто великі. У цих вбудованих функцій має бути мало вентиляторів, і якщо у них є вентилятор, він повинен бути локалізований для речей, визначених у заголовку.

Що являє собою мінімальний набір #includeтверджень?

Це виявляється нетривіальним питанням. Визначення TL; DR: файл заголовка повинен містити файли заголовків, які безпосередньо визначають кожен із типів, які безпосередньо використовуються, або які безпосередньо декларують кожну з функцій, що використовуються у відповідному файлі заголовка, але не повинні включати нічого іншого. Тип вказівника чи C ++ не кваліфікується як безпосереднє використання; прямі посилання є кращими.

Є місце для безоплатної #includeдирективи, і це в автоматизованому тесті. Для кожного файлу заголовка в програмному пакеті я автоматично генерую та збираю наступне:

#include "path/to/random/header_under_test"
int main () { return 0; }

Компіляція повинна бути чистою (тобто без будь-яких попереджень або помилок). Попередження або помилки щодо неповних типів або невідомих типів означають, що у тестовому файлі заголовка є деякі відсутні #includeдирективи та / або відсутні декларації вперед. Зверніть увагу: Тільки те, що проходження тесту не означає, що набір #includeдиректив достатній, не кажучи вже про мінімальний.

Крім того, що вже було сказано.

H-файли завжди повинні містити:

• Документація на вихідний код !!! Як мінімум, яке призначення різних параметрів і повернення значень функцій.
• Захист заголовка, #ifndef MYHEADER_H #define MYHEADER_H ... #endif

Файли H ніколи не повинні містити:

• Будь-яка форма розподілу даних.
• Визначення функції. Вбудовані функції можуть бути рідкісним винятком у деяких випадках.
• Все, що маркується static.
• Typedefs, #defines або константи, які не мають відношення до решти програми.

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

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

Макроси, вбудовані функції та шаблони можуть виглядати як дані чи код, але вони не генерують код під час їх розбору, а замість того, коли вони використовуються. Ці елементи часто потрібно використовувати в більш ніж одному .c або .cpp, тому вони належать до .h.

На мій погляд, заголовок-файл повинен мати мінімальний практичний інтерфейс до відповідного .c або .cpp. Інтерфейс може включати #defines, class, typedef, визначення структур, прототипи функцій та менш бажані зовнішні визначення глобальних змінних. Однак якщо декларація використовується лише в одному вихідному файлі, вона, ймовірно, повинна бути виключена з .h і замість цього міститися у вихідному файлі.

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

Файл заголовка повинен мати таку організацію:

• тип та постійні визначення
• декларації зовнішніх об'єктів
• зовнішні декларації функції

Файли заголовків ніколи не повинні містити визначення об’єктів, лише визначення типів та декларації об'єкта.

Заяви, які генерують дані та код під час їх розбору, не повинні містити .hфайл. Що стосується моєї точки зору, файл заголовка повинен мати лише мінімальний практичний інтерфейс до відповідного .cабо .cpp.