Чи слід використовувати передові декларації замість включень, де це можливо?

Question 1

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

//file C.h
#include "A.h"
#include "B.h"

class C{
    A* a;
    B b;
    ...
};

зробіть це замість цього:

//file C.h
#include "B.h"

class A;

class C{
    A* a;
    B b;
    ...
};


//file C.cpp
#include "C.h"
#include "A.h"
...

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

Question 2

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

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

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

Question 3

Так, використання прямих декларацій завжди краще.

Деякі переваги, які вони надають:

Скорочений час складання.
Не забруднює простір імен.
(У деяких випадках) може зменшити розмір ваших сформованих двійкових файлів.
Час рекомпіляції можна значно скоротити.
Уникнення потенційного зіткнення назв препроцесора.
Реалізація PIMPL Idiom, таким чином, забезпечує приховування реалізації від інтерфейсу.

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

За допомогою неповного типу ви можете:

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

При неповному типі ви не можете:

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

Question 4

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

Зручність.

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

Це досить дотепна тема, оскільки занадто ліберальне використання цього правила великих пальців дасть майже некомпільований код. Зауважте, що Boost підходить до проблеми по-різному, надаючи конкретні заголовки «зручності», які об’єднують пару тісних функціональних можливостей.

Question 5

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

// Forward declarations
template <typename A> class Frobnicator;
template <typename A, typename B, typename C = Frobnicator<A> > class Gibberer;

// Alternative: more clear to the reader; more stable code
#include "Gibberer.h"

// Declare a function that does something with a pointer
int do_stuff(Gibberer<int, float>*);

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

Question 6

Цікаво, що у своєму керівництві стилем C ++ Google рекомендує використовувати #includeскрізь, але щоб уникнути кругових залежностей.

Question 7

Чи слід використовувати передові декларації замість включень, де це можливо?

Ні, явні прямі декларації не повинні розглядатися як загальне керівництво. Переадресаційні декларації - це, по суті, копія та вставка, або неправильно написаний код, який у разі виявлення помилки в ньому потрібно виправити всюди, де використовуються переадресовані оголошення. Це може спричинити помилки.

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

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

Ось кілька прикладів "невидимих ризиків" щодо прямих оголошень (невидимі ризики = невідповідність оголошень, які не виявляються компілятором або компонувальником):

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

Наведений нижче приклад ілюструє це, наприклад, дві небезпечні декларації вперед даних, а також функції:

Файл змінного струму:

#include <iostream>
char data[128][1024];
extern "C" void function(short truncated, const char* forgotten) {
  std::cout << "truncated=" << std::hex << truncated
            << ", forgotten=\"" << forgotten << "\"\n";
}

Файл bc:

#include <iostream>
extern char data[1280][1024];           // 1st dimension one decade too large
extern "C" void function(int tooLarge); // Wrong 1st type, omitted 2nd param

int main() {
  function(0x1234abcd);                         // In worst case: - No crash!
  std::cout << "accessing data[1270][1023]\n";
  return (int) data[1270][1023];                // In best case:  - Boom !!!!
}

Компіляція програми з g ++ 4.7.1:

> g++ -Wall -pedantic -ansi a.c b.c

Примітка: Невидима небезпека, оскільки g ++ не видає помилок / попереджень компілятора або компонувальника.
Примітка: Опускання extern "C"призводить до помилки прив'язки function()через маніпулювання іменем c ++.

Запуск програми:

> ./a.out
truncated=abcd, forgotten="♀♥♂☺☻"
accessing data[1270][1023]
Segmentation fault

Question 8

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

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

Попереднє оголошення функції:

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

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

Попереднє оголошення класу:

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

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

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

Інший варіант - використовувати ідіому pimpl, яка ще краще приховує деталі реалізації та пришвидшує компіляцію за рахунок невеликих накладних витрат.

Question 9

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

Єдина причина, про яку я думаю, - це зберегти певний текст.

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

Question 10

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

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

На моєму ПК функція Faster () працює приблизно в 2000 разів швидше, ніж функція Slower ():



class SomeClass
{
public:
    void DoSomething()
    {
        val++;
    }
private:
    int val;
};

class UsesPointers
{
public:
    UsesPointers() {a = new SomeClass;}
    ~UsesPointers() {delete a; a = 0;}
    SomeClass * a;
};

class NonPointers
{
public:
    SomeClass a;
};

#define ARRAY_SIZE 100000
void Slower()
{
    UsesPointers list[ARRAY_SIZE];
    for (int i = 0; i < ARRAY_SIZE; i++)
    {
        list[i].a->DoSomething();
    }
}

void Faster()
{
    NonPointers list[ARRAY_SIZE];
    for (int i = 0; i < ARRAY_SIZE; i++)
    {
        list[i].a.DoSomething();
    }
}

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

Це хороша презентація з цього питання та інших факторів ефективності: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf