Вперед декларация включает, помимо объявления включить (ClassFwd.h + Class.h)

Question

В Эффективном C++ (3-е издание) Скотт Мейерс в пункте 31 предполагает, что классы должны иметь, помимо своей классической Декларации (. h) и определения (.cpp), файл декларации Forward Forward Include (fwd.h), который может не использоваться для полного определения, а не для объявления вперед.

Я немного смотрю на это дело, но я действительно не вижу в этом жизнеспособного варианта ... Кажется, очень трудно поддерживать, а скорее излишне и вряд ли нужно.

Я могу, однако, увидеть его использование для форвардных объявлений шаблонов, которые довольно тяжелые. Но для простых классов? Похоже, что это боль в обслуживании и создаст много почти пустых файлов, которые служат очень маленькой цели ... стоит ли хлопот?

Вот пример:

// Class.h 
class Class 
{ 
    Class(); 
    ~Class(); 
}; 

// ClassFwd.h 
class Class; 

// Class.cpp 
Class::Class() 
{ 
} 

Class::~Class() 
{ 
} 

Мой вопрос:

Что вы думаете, ребята? Если это хорошая практика?

ПРИМЕЧАНИЕ Меня больше интересуют аргументы. Для этой практики, чтобы увидеть, пропустил ли я что-то, что позволило бы мне согласиться с Скоттом Мейерсом.

Answer 1

Я использовал вперед файлы заголовки декларации для всех моих библиотек библиотеки, как правило, имеет такую ​​структуру:..

lib/ 
    include/ 
    class headers + Fwd.h 
src/ 
    source files + internal headers 

каталог lib/include будет содержать все общественные классы заголовков вместе с заголовком одной декларации вперед Это сделало библиотеку свето- вес на стороне включения. Любой заголовок за пределами этой библиотеки включает только прямой заголовок (Fwd.h), а источники за пределами этой библиотеки включают в себя необходимое co mplete headers. Можно также предоставить заголовок удобства (Lib.h), который включает в себя все остальные заголовки для использования в исходных файлах.

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

Вышеупомянутый полезен для больших приложений с большим количеством внутренних библиотек. Уточнение вышеприведенного для этого случая было бы разместить публичные заголовки в lib/include/lib. Таким образом, клиенты вашей библиотеки должны будут включать lib/.... Подумайте об этом как о пространстве имен для ваших заголовков.

Удачи вам!

Answer 2

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

struct A { 
    B* m_pB; 
}; 

struct B { 
    A* m_pA; 
}; 

Теперь А и В может быть разумно в различных файлах, может быть, даже различные проекты. Тем не менее, их зависимость - это не какой-то дефект дизайна, а вполне логичный и необходимый. Чем ты занимаешься?

1. Сначала включите один заголовок Forward.h для заголовка. Для требуемого проекта eeach, т. Е. В декларации forward нет собственного файла заголовка для каждого класса.
2. Затем включите класс.h всех необходимых проектов. Для этих заголовков потребуются форвардные декларации для компиляции.
3. Включите заголовки основного проекта.

В довольно большом решении (500k LOC) я нашел этот шаблон очень легко управляемым. В противном случае, если вы измените объявление класса, где вы найдете все объявления вперед, которые могут быть сделаны отдельно в любом количестве других файлов заголовков?

Answer 3

Размещение простого class Whatever; в его собственном заголовке не имеет преимуществ и множества недостатков.

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

С шаблонами, как вы заметили, это другое дело. Например. проверьте <iosfwd> из стандартной библиотеки.

Cheers & hth.

Answer 4

Практика позволяет пользователю кода не думать о том, является ли класс регулярным или шаблонным. Пользователь просто # включает "соответствующее_fwd.h "и имеет ссылку на класс. Еще одно раздражение для пользователя - это хорошая вещь. Но если это небольшой проект или создатель класса - единственный пользователь класса, тогда это может быть более раздражающим. Поэтому это зависит.