Где лучше включать заголовочные файлы?

Question

[Даниил Демидко]

Для примера:
У меня есть класс, описанный в MyClass.h, и его реализация в MyClass.cpp
Описание класса требует только string

//MyClass.h
#pragma once
#include<string>
class MyClass {
public:
 std::string ExampleFunction();
}

Но его тело в MyClass.cpp может использовать другие хедеры помимо string, например vector.

//MyClass.cpp
#include "MyClass.h"
//Дальше описание тела

Так вот вопрос: где лучше подключить эти хедеры - в MyClass.h или в MyClass.cpp ?

Answer 1

[teugen]

Вот, например, хороший ответ.

This rule means that if the header uses a type - such as 'FILE *' or 'size_t' - then it must ensure that the appropriate other header ( or for example) should be included. A corollary, often forgotten, is that the header should not include any other header that is not needed by the user of the package in order to use the package. The header should be minimal, in other words.

Вкратце: включений в заголовке должно быть как можно меньше, при этом в нём должны быть включены все заголовки, необходимые для беспрепятственной работы кода, в нём описанного.

В вашем случае, если vector используется исключительно в реализации и в описании blackbox'a никак себя не проявляет, включать его нужно в .cpp

Answer 2

[Vitaly]

Выше всё верно написали, но перед тем как просто следовать рекомендациям, хорошо бы ответить на вопрос: "зачем?". Все дело в основном (хотя бывают и другие случаи) в скорости компиляции программы. Поменяли что-то в заголовочнике, который включен в 100500 других заголовочников и ушли отдыхать на 15 минут, пока всё это компилится в 8 потоков :) Неприятно в общем. Т.е. золотое правило: чем меньше включено в заголовочник, тем лучше. Правда, в 17ом стандарте будут модули и эта проблема решится (ну всё равно тонны легаси никто сразу вот так прям не портирует, так что еще лет 5-10 эти знания будут актуальны).
Помимо этого, для увеличения скорости компиляции можно использовать pimpl (но осторожно, это не основное предназначение этой техники!) и программы вроде ccache (как, вы всё еще не на линуксе?).

Answer 3

[Станислав Макаров]

К teugen добавлю, что если вы используете не значение класса/структуры, а указатель на него, то в хедер вместо инклуда другого хедера можно вставить объявление класса:

#pragma once
class ExampleClass;
class MyClass {
public:
 ExampleClass* ExampleFunction();
};

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

Comments

[Даниил Демидко]

хм, а почему бы тогда вообще не обьявлять с рализацией классы в .cpp, а .h не оставлять только обьявление?

[Станислав Макаров]

Даниил Демидко
> а инклуд определения класса делать там, где без него уже никак - например там, где вызываются методы класса или создаются его экземпляры.

Чтобы создать экземпляр, компилятору нужно иметь определение класса. Чтобы вызвать метод экзмепляра, также нужно иметь определение класса (иначе компилятор не сможет понять, а есть ли вообще такой метод, и действительно ли у него такие формальные параметры).

Поймите, по сути разбиение на h/cpp это такой хак, необходимый из-за отсутствия (пока что) модульности в C++. Из-за того, что компилятор не умеет собирать информацию по нескольким файлам исходников (как в других языках), при компиляции конкретного cpp компилятору нужна ВСЯ необходимая информация для обработки исходного кода в этом cpp. Наличие этой информации достигается использованием инклудов - вы как бы просите препроцессор собрать для компилятора всю нужную информацию в один файл (который кстати будет намного толще в случае большой иерархии хедеров). Это и определения классов, и typedef-ы, и реализации ШАБЛОННЫХ методов и функций и т.д. После этого компилятор прочтет все нужные определения и сможет ими воспользоваться в нужных местах при обработке кода, находящегося в исходном cpp.
Однако, т.к. конечный бинарник будет линковаться линкером, то при компиляции отдельной "единицы компиляции" (т.е. нашего cpp) нет необходимости иметь определения обыкновенных (нешаблонных) функций и методов - ссылки на них будет ставить уже линковщик. Поэтому правило простое - все МАКСИМАЛЬНО выносится в "единицу компиляции", а та информация, без которой невозможно собирать остальной зависимый код - в хедер. Поэтому, например, реализации методов класса - в cpp, а определение самого класса - в хедере.
Из-за этого кстати появляются различные проблемы, например недостаточная абстракция реализации класса от интерфейса - т.к. экземпляры класса создаются не опосредованно через фабрики, а непосредственно по их определению в месте использования new, то при изменении определения класса (например, добавлении поля или изменении его типа) требуется перекомпиляция всего зависимого кода, т.к. может измениться размер объекта, и вообще нарушиться бинарная совместимость (т.е. DLL-ку/SO-шку уже просто так не поменяешь). Для решения этой проблемы используется, например, упомянутый Vitaly pImpl (там, где бинарную совместимость очень уж хочется). Есть и другие способы, например создание вынесение публичного интерфейса и создание пар функций-фабрик (create/destroy), чтобы переместить код создания/удаления внутрь нужного бинарника.