Чому для C ++ потрібен окремий файл заголовка?

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

C ++ був ратифікований у 1998 році, тож чому він розроблений таким чином? Які переваги має окремий файл заголовка?

Наступне запитання:

Як компілятор знаходить файл .cpp з кодом у ньому, коли все, що я включаю, це .h файл? Чи передбачається, що .cpp-файл має те саме ім'я, що і .h-файл, чи він насправді переглядає всі файли у дереві каталогів?

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

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

Причини, від яких ви хочете відокремитись:

1. Щоб покращити час збирання.
2. Пов’язати проти коду, не маючи джерела для визначень.
3. Щоб уникнути маркування всього "встроєного".

Якщо ваше більш загальне питання: "чому C ++ не є тотожним Java?", То я повинен запитати: "чому ви пишете C ++ замість Java?" ;-p

Більш серйозно, однак, причина полягає в тому, що компілятор C ++ не може просто проникнути в інший блок перекладу і придумати, як використовувати його символи таким чином, як javac може і робить. Файл заголовка необхідний, щоб оголосити компілятору те, що він може очікувати, що він буде доступний під час посилання.

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

Перетворення моїх коментарів, щоб відповісти на ваше подальше запитання:

Як компілятор знаходить .cpp-файл із кодом у ньому

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

C ++ робить це так, оскільки C зробив це саме так, тому справжнє питання полягає в тому, чому C зробив це саме так? Вікіпедія трохи говорить на це.

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

Деякі люди вважають переваги файлів заголовків:

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

Зрештою, система заголовків - це артефакт із 70-х років, коли проектувався C. Тоді комп'ютери мали дуже мало пам’яті, і зберігати весь модуль у пам’яті просто не було варіантом. Компілятор повинен був почати читати файл у верхній частині, а потім продовжувати лінійно через вихідний код. Механізм заголовків дозволяє це. Компілятору не потрібно враховувати інші перекладацькі одиниці, він просто повинен читати код зверху вниз.

І C ++ зберегла цю систему для зворотної сумісності.

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

Однак однією з пропозицій для C ++ 0x було додати належну модульну систему, що дозволить компілювати код, подібний до .NET або Java, у більші модулі, все за один раз і без заголовків. Ця пропозиція не зменшила C ++ 0x, але я вважаю, що вона все ще в категорії "ми б хотіли зробити це пізніше". Можливо, у TR2 чи подібному.

На мій погляд (обмежено - я зазвичай не розробник C), це корінням у C. Пам'ятайте, що C не знає, що таке класи або простори імен, це лише одна довга програма. Також функції потрібно оголосити перед їх використанням.

Наприклад, наступне має дати помилку компілятора:

void SomeFunction() {
    SomeOtherFunction();
}

void SomeOtherFunction() {
    printf("What?");
}

Помилка повинна полягати в тому, що "SomeOtherFunction не оголошено", тому що ви викликаєте це ще до його оголошення. Один із способів виправити це - переміщенням SomeOtherFunction над SomeFunction. Інший підхід - спочатку оголосити функції підпису:

void SomeOtherFunction();

void SomeFunction() {
    SomeOtherFunction();
}

void SomeOtherFunction() {
    printf("What?");
}

Це дає можливість компілятору знати: Подивіться десь у коді, є функція під назвою SomeOtherFunction, яка повертає недійсність і не приймає жодних параметрів. Тож якщо ви сприяєте коду, який намагається викликати SomeOtherFunction, не панікуйте, а натомість шукайте його.

Тепер уявіть, що у вас є SomeFunction та SomeOtherFunction у двох різних .c-файлах. Тоді вам доведеться #include "SomeOther.c" у Some.c. Тепер додайте деякі "приватні" функції в SomeOther.c. Оскільки C не знає приватних функцій, ця функція буде доступна і в Some.c.

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

Отже, головна причина - це зручність, захист вихідного коду та трохи роз’єднання між частинами програми.

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

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

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

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

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

Такі мови, як Java або C #, з іншого боку, включають інформацію, необхідну для прив'язки, у висновку компілятора (клас-файл або збірка). Отже, більше немає необхідності підтримувати окремі декларації для включення клієнтами модуля.

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

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

Так, у цей момент (через 10 років після першого стандарту C ++ та 20 років після того, як він почав серйозно зростати у використанні), легко запитати, чому він не має належної модульної системи. Очевидно, що будь-яка нова мова, що розробляється сьогодні, не працюватиме як C ++. Але це не сенс C ++.

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

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

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

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

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

Скажіть, у мене є foo.cpp, і я хочу використовувати код з файлів bar.h / bar.cpp.

Я можу #include "bar.h" у foo.cpp, а потім програмувати і компілювати foo.cpp, навіть якщо bar.cpp не існує. Файл заголовка виступає обіцянням компілятору, що класи / функції в bar.h будуть існувати під час виконання, і він має все, що потрібно знати вже.

Звичайно, якщо у функції bar.h немає тіл, коли я намагаюся зв’язати свою програму, вона не зв’яжеться, і я отримаю помилку.

Побічним ефектом є те, що ви можете надати користувачам заголовний файл, не розкриваючи свій вихідний код.

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

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

Це дійсно проблема сфери.

C ++ був ратифікований у 1998 році, тож чому він розроблений таким чином? Які переваги має окремий файл заголовка?

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

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

Ну, ви бездоганно можете розробити C ++ без файлів заголовків. Насправді деякі бібліотеки, які інтенсивно використовують шаблони, не використовують парадигму файлів заголовків / кодів (див. Прискорення). Але в C / C ++ ви не можете використовувати те, що не задекларовано. Один практичний спосіб впоратися з цим - використовувати файли заголовків. Крім того, ви отримуєте перевагу спільного використання інтерфейсу без коду / реалізації. І я думаю, що це не було передбачено творцями C: Коли ви використовуєте спільні файли заголовків, ви повинні використовувати відомі:

#ifndef MY_HEADER_SWEET_GUARDIAN
#define MY_HEADER_SWEET_GUARDIAN

// [...]
// my header
// [...]

#endif // MY_HEADER_SWEET_GUARDIAN

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

Отже, я думаю, що коли С створювався, проблеми з декларуванням вперед були недооцінені, і зараз, коли використовуємо мову високого рівня, як C ++, ми маємо мати справу з подібними речами.

Ще одне тягар для нас, бідних користувачів C ++ ...

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