Чому мають заголовки та .cpp файли? [зачинено]

Чому у C ++ є файли заголовків та .cpp-файли?

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

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

Це не ідеально, і ви зазвичай вдаєтеся до таких методів, як Pimpl Idiom, щоб правильно розділити інтерфейс та реалізацію, але це вдалий початок.

С ++ компіляція

Компіляція на C ++ виконується в 2 основні фази:

1. Перший - це компіляція "вихідних" текстових файлів у бінарні "об'єктні" файли. Файл CPP - це скомпільований файл і збирається без будь-яких знань про інші файли CPP (або навіть бібліотеки), за винятком випадків, коли він подається до нього через неочищене оголошення або включення заголовка Файл CPP зазвичай компілюється у .OBJ або .O "об'єктний" файл.

2. Друге - це з'єднання всіх файлів "об'єкта", а отже, створення остаточного бінарного файлу (або бібліотеки, або виконуваного файлу).

Де ГЕС поміщається у всьому цьому процесі?

Поганий самотній файл CPP ...

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

// A.CPP
void doSomething()
{
   doSomethingElse(); // Defined in B.CPP
}

// B.CPP
void doSomethingElse()
{
   // Etc.
}

Він не компілюється, оскільки у A.CPP немає способу дізнатися, чи існує "doSomethingElse" ... Якщо в A.CPP немає декларації, наприклад:

// A.CPP
void doSomethingElse() ; // From B.CPP

void doSomething()
{
   doSomethingElse() ; // Defined in B.CPP
}

Потім, якщо у вас є C.CPP, який використовує той самий символ, ви копіюєте / вставляєте декларацію ...

КОПІЯ / ПАСТИЧНИЙ АЛЕРТ!

Так, є проблема. Копії / пасти небезпечні та важкі в обслуговуванні. Що означає, що було б здорово, якби ми мали якийсь спосіб НЕ скопіювати / вставити, а все-таки оголосити символ ... Як це зробити? До включення деякого текстового файлу, який зазвичай суфіксовано .h, .hxx, .h ++ або, моїм кращим для файлів C ++, .hpp:

// B.HPP (here, we decided to declare every symbol defined in B.CPP)
void doSomethingElse() ;

// A.CPP
#include "B.HPP"

void doSomething()
{
   doSomethingElse() ; // Defined in B.CPP
}

// B.CPP
#include "B.HPP"

void doSomethingElse()
{
   // Etc.
}

// C.CPP
#include "B.HPP"

void doSomethingAgain()
{
   doSomethingElse() ; // Defined in B.CPP
}

Як includeпрацює?

Включення файлу, по суті, буде аналізувати, а потім копіювати та вставляти його вміст у файл CPP.

Наприклад, у наступному коді із заголовком A.HPP:

// A.HPP
void someFunction();
void someOtherFunction();

... джерело B.CPP:

// B.CPP
#include "A.HPP"

void doSomething()
{
   // Etc.
}

... стане після включення:

// B.CPP
void someFunction();
void someOtherFunction();

void doSomething()
{
   // Etc.
}

Одна невелика річ - навіщо включати B.HPP до B.CPP?

У поточному випадку це не потрібно, і B.HPP має doSomethingElseдекларацію функції, а B.CPP має doSomethingElseвизначення функції (що саме по собі є декларацією). Але в більш загальному випадку, коли B.HPP використовується для декларацій (та вбудованого коду), не може бути відповідного визначення (наприклад, перерахунки, прості структури тощо), тому включення може знадобитися, якщо B.CPP використовує ці декларації від B.HPP. Загалом, джерело має "гарний смак", щоб за замовчуванням включити його заголовок.

Висновок

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

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

#ifndef B_HPP_
#define B_HPP_

// The declarations in the B.hpp file

#endif // B_HPP_

або навіть простіше

#pragma once

// The declarations in the B.hpp file

Оскільки C, звідки виникла концепція, вже 30 років, і тоді це був єдиний життєздатний спосіб зв’язати разом код з кількох файлів.

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

Оскільки в C ++ остаточний виконуваний код не несе ніякої символьної інформації, це більш-менш чистий машинний код.

Таким чином, вам потрібен спосіб описати інтерфейс фрагмента коду, який є окремим від самого коду. Цей опис знаходиться у файлі заголовка.

Тому що C ++ успадкував їх від C. На жаль.

Оскільки люди, які розробили формат бібліотеки, не хотіли "витрачати" простір на рідко використовувану інформацію, таку як макроси препроцесора C та декларації функцій.

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

Більшість мов після C / C ++ зберігають цю інформацію у висновку (наприклад, байт-код Java) або вони взагалі не використовують попередньо складений формат, завжди їх розповсюджують у вихідному вигляді та збирають на льоту (Python, Perl).

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

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

У рамках одного проекту використовуються файли заголовків, IMHO, принаймні для двох цілей:

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

Відповідаючи на відповідь MadKeithV ,

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

Ще одна причина полягає в тому, що заголовок дає унікальний ідентифікатор кожному класу.

Тож якщо у нас є щось подібне

class A {..};
class B : public A {...};

class C {
    include A.cpp;
    include B.cpp;
    .....
};

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