Справа в тому, що в C ++ це дещо складніше, ніж в заголовку / організації джерела.
Що бачить компілятор?
Компілятор бачить один великий джерельний (.cpp) файл із належними заголовками. Вихідний файл - це блок компіляції, який буде зібраний у файл об'єкта.
Отже, навіщо потрібні заголовки?
Оскільки одному блоку компіляції може знадобитися інформація про реалізацію в іншому блоці компіляції. Отже, можна написати, наприклад, реалізацію функції в одному джерелі, і написати декларацію цієї функції в іншому джерелі, що потребує її використання.
У цьому випадку є дві копії однакової інформації. Що це зло ...
Рішення - поділитися деякими деталями. Хоча реалізація повинна залишатися у Джерелі, декларація спільних символів, як-от функцій, або визначення структур, класів, перерахунків тощо, може бути спільним.
Заголовки використовуються для розміщення цих спільних даних.
Перемістіть до заголовка заяви про те, що потрібно поділити між кількома джерелами
Більше нічого?
У C ++ є деякі інші речі, які можна помістити в заголовок, оскільки їх також потрібно розділити:
- вбудований код
- шаблони
- постійні (зазвичай ті, які ви хочете використовувати всередині комутаторів ...)
Перемістіть до заголовка ВСЕ, що потрібно поділитись, включаючи спільні реалізації
Чи означає це тоді, що всередині заголовків можуть бути джерела?
Так. Насправді, існує багато різних речей, які можуть бути всередині "заголовка" (тобто поділяються між джерелами).
- Переадресація декларацій
- декларації / визначення функцій / структур / класів / шаблонів
- реалізація вбудованого та шаблонного коду
Це ускладнюється, а в деяких випадках (кругові залежності між символами) неможливо зберегти його в одному заголовку.
Заголовки можна розбити на три частини
Це означає, що в крайньому випадку у вас можуть бути:
- заголовок прямої декларації
- заголовок декларації / визначення
- заголовок реалізації
- джерело реалізації
Давайте уявимо, що у нас є шаблонний MyObject. Ми могли б мати:
// - - - - MyObject_forward.hpp - - - -
// This header is included by the code which need to know MyObject
// does exist, but nothing more.
template<typename T>
class MyObject ;
.
// - - - - MyObject_declaration.hpp - - - -
// This header is included by the code which need to know how
// MyObject is defined, but nothing more.
#include <MyObject_forward.hpp>
template<typename T>
class MyObject
{
public :
MyObject() ;
// Etc.
} ;
void doSomething() ;
.
// - - - - MyObject_implementation.hpp - - - -
// This header is included by the code which need to see
// the implementation of the methods/functions of MyObject,
// but nothing more.
#include <MyObject_declaration.hpp>
template<typename T>
MyObject<T>::MyObject()
{
doSomething() ;
}
// etc.
.
// - - - - MyObject_source.cpp - - - -
// This source will have implementation that does not need to
// be shared, which, for templated code, usually means nothing...
#include <MyObject_implementation.hpp>
void doSomething()
{
// etc.
} ;
// etc.
Оце Так!
У "реальному житті" це, як правило, менш складно. Більшість кодів матимуть лише просту організацію заголовка / джерела, з деяким вбудованим кодом у джерелі.
Але в інших випадках (шаблонні об'єкти, які знають одне одного), я повинен був мати для кожного об'єкта окремі заголовки оголошень та реалізації, з порожнім джерелом, що включає ці заголовки, лише щоб допомогти мені побачити деякі помилки компіляції.
Ще однією причиною розбиття заголовків на окремі заголовки може стати прискорення компіляції, обмеження кількості символів, розібраних на суворо необхідне, та уникнення непотрібної перекомпіляції джерела, яке піклується лише про пряму декларацію, коли змінилася реалізація вбудованого методу.
Висновок
Ви повинні зробити свою організацію коду максимально простою і максимально модульною. Покладіть якомога більше у вихідний файл. Розкрийте лише в заголовках те, що потрібно поділитись.
Але в той день, коли ви матимете кругові залежності між шаблонованими об’єктами, не дивуйтесь, якщо ваша організація коду стане дещо «цікавішою», ніж звичайна організація заголовка / джерела ...
^ _ ^