Следует ли использовать форвардные объявления вместо того, чтобы включать туда, где это возможно?

Question

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

//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" 
... 

Есть ли причина, почему не делать это везде, где это возможно?

Answer 1

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

Там нет минусов в ФОРВАРДНОМ объявляя классы, но я могу думать о некоторых недостатках для включения заголовков ненужно:

• больше времени компиляции, так как все единицы перевода, включая C.h будут также включать A.h, хотя они может не понадобиться.

• включая, возможно, другие заголовки вам не нужны косвенно

• загрязняя единицы перевода с символами вам не нужно

• вам, возможно, потребуется перекомпилировать исходные файлы, которые содержат этот заголовок, если он изменяет (@PeterWood)

Answer 2

Да, использование форвардных деклараций всегда лучше.

Некоторые из преимуществ, которые они обеспечивают, являются:

• Сокращение времени компиляции.
• Без пространства имен загрязнять.
• (В некоторых случаях) может уменьшить размер сгенерированных двоичных файлов.
• Время перекомпиляции может быть значительно уменьшено.
• Избегайте потенциального столкновения имен препроцессора.
• Внедрение PIMPL Idiom Таким образом, обеспечивается средство скрытия реализации от интерфейса.

Однако, вперед объявить класс делает этот конкретный класс Неполное типа и серьезно ограничивает, какие операции можно выполнять на неполном типа.
Вы не можете выполнять какие-либо операции, которые необходимы компилятору для определения макета класса.

С неполном типа вы можете:

• Declare член как указатель или ссылку на неполный тип.
• Объявлять функции или методы, которые принимают/возвращают неполные типы.
• Определите функции или методы, которые принимают/возвращают указатели/ссылки на неполный тип (но не используют его элементы).

С неполном типа вы не можете:

• использовать его в качестве базового класса.
• Используйте это, чтобы объявить участников.
• Определите функции или методы, используя этот тип.

Answer 3

Есть ли причина, по которой это невозможно сделать, когда это возможно?

Единственная причина, по которой я думаю, состоит в том, чтобы сохранить некоторую типизацию.

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

Answer 4

Есть ли причина, по которой это невозможно сделать, когда это возможно?

Удобство.

Если вы знаете заранее, что любой пользователь этого файла заголовка обязательно должен также включить определение A, чтобы что-либо сделать (или, возможно, большую часть времени). Тогда удобно просто включить его раз и навсегда.

Это довольно осязаемый предмет, поскольку слишком либеральное использование этого правила большого пальца даст почти несовместимый код. Обратите внимание, что Boost подходит к проблеме по-разному, предоставляя определенные «удобные» заголовки, которые объединяют несколько близких функций вместе.

Answer 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 места или больше каждый раз, и это нехорошо.

Answer 6

Есть ли причина, по которой это невозможно сделать, когда это возможно?

Да - Производительность. Объекты класса хранятся вместе с элементами данных в памяти. Когда вы используете указатели, память для фактического объекта, на который указывает, хранится в другом месте в куче, как правило, далеко. Это означает, что доступ к этому объекту приведет к промаху и перезагрузке кеша. Это может иметь большое значение в ситуациях, когда производительность имеет решающее значение.

На моем компьютере функции Быстрее() проходит около 2000X быстрее, чем функция более медленной():

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

Answer 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"; 
} 

Ьс Файл:

#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 

Примечание: Invisible опасность, поскольку г ++ не дает никакой компилятор или компоновщик ОШИБКИ/предупреждения
Примечание: Опуская extern "C" приводит к связующей погрешности для function() в связи с C++ имя коверкая.

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

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

Answer 8

Забавный факт, in its C++ styleguide, Google recommands используя #include везде, но, чтобы избежать циклических зависимостей.

Answer 9

Есть ли причина, по которой это невозможно сделать, когда это возможно?

Абсолютно: он разрушает инкапсуляцию, требуя от пользователя класса или функции знать и дублировать детали реализации. Если эти детали реализации изменяются, код, который объявляет вперед, может быть нарушен, а код, который опирается на заголовок, будет продолжать работать.

вперед объявление функции:

• требует, зная, что он реализован в виде функции, а не экземпляр статического объекта функтора или (удушье!) Макрос,

• требует дублирования по умолчанию значения для параметров по умолчанию,

• требует знать свое фактическое имя и пространство имен, так как это может быть только объявление using, которое вытаскивает его в другое пространство имен, возможно, под псевдоним, и

• может потерять при встроенной оптимизации.

Если код потребления зависит от заголовка, то все эти детали реализации могут быть изменены поставщиком функций без нарушения кода.

вперед объявить класс:

• требует знать, является ли это производный класс и базовый класс (а) это происходит от,

• требует зная, что это класс, а не только ЬурейеЕ или конкретное создание шаблона класса (или знание того, что это шаблон класса, и правильная настройка всех параметров шаблона и значений по умолчанию),

• требует знать истинное имя и пространство имен t он класс, так как это может быть объявление using, которое тянет его в другое пространство имен, возможно, под псевдонимом, и

• требует знания правильных атрибутов (возможно, у него есть особые требования к выравниванию).

Опять же, форвардное объявление ломает инкапсуляцию этих деталей реализации, делая ваш код более хрупким.

Если вам нужно сократить зависимости заголовка, чтобы ускорить время компиляции, затем получите провайдера класса/функции/библиотеки для предоставления специального заголовка форвардных объявлений. Стандартная библиотека делает это с <iosfwd>. Эта модель сохраняет инкапсуляцию деталей реализации и дает разработчику библиотеки возможность изменять эти детали реализации, не нарушая ваш код, при одновременном уменьшении нагрузки на компилятор.

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