Что должно войти в.h файл?

заголовочный файл (.h) должен быть для деклараций классов, структур и их методов, прототипов и др. Реализация этих объектов производится в cpp.

in . h

    class Foo {
    int j;

    Foo();
    Foo(int)
    void DoSomething();
}

Я бы ожидал увидеть:

• объявления
• комментарии
• определения, помеченные inline
• шаблоны

, хотя на самом деле ответ - это то, что не следует вводить:

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

The header Defines something but doesn't tell anything about the implementation. ( Исключая шаблоны в этом "метафоре".

При этом нужно разделить "определения" на подгруппы, в данном случае есть два типа определений.

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

Теперь, конечно, я говорю о первой подгруппе.

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

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

• Заголовочные файлы - не стоит слишком часто менять при разработке -> надо думать и писать их сразу (в идеальном случае)
• Исходные файлы - изменения при реализации

Заголовок (.h)

• Макросы и включает в себя необходимые для интерфейсов (как можно меньше)
• Объявление функций и классов
• Документация по интерфейсу
• Объявление встроенных функций/методов, если таковые имеются
• экстернов к глобальным переменным (если таковые имеются)

Тело (. cpp)

• Rest of macros and includes
• Include the header of the module
• Definition of functions and methods
• Global variables (if any)

Rest of macros and includes

As a rule of thumb, you put the "shared" part on the .h (the part that other modules must be able to see) and the "not shared" part on the .cpp

PD: Yes, I've included global variables. Я использовал их несколько раз, и важно не определять их в заголовках, иначе вы получите множество модулей, каждый из которых определяет свою собственную переменную.

EDIT: Модифицировано после комментария David

Дело в том, что на Си++ это несколько сложнее, чем организация заголовков/исходников на Си.

Что видит компилятор?

Компилятор видит один большой исходный (.cpp) файл с правильно включенными заголовками. Исходный файл - это единица компиляции, которая будет скомпилирована в объектный файл.

Так зачем нужны заголовки?

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

В этом случае существует два экземпляра одной и той же информации. Что является злом...

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

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

Ничего больше?

В C++ есть некоторые другие вещи, которые можно поместить в заголовок, потому что они тоже должны быть общими:

• inline code
• templates
• constants (обычно те, которые вы хотите использовать внутри коммутаторов). ...)

Переместите в заголовок ВСЕ, что должно быть общим, включая общие реализации

Значит ли это, что внутри заголовков могут быть исходники?

Да. На самом деле, есть много разных вещей, которые могут быть внутри "заголовка" (i. e. shared between sources).

• Forward declarations
• declarations/definition of functions/structs/classes/templates
• implementation of inline and templated code

It becomes complicated, and in some cases (круговые зависимости между символами), impossible to keep it in one header. Заголовки можно разбить на три части

Это означает, что в крайнем случае можно иметь:

• заголовок прямой декларации
• заголовок декларации/определения
• заголовок реализации
• источник реализации

Представьте себе, что у нас есть шаблонированный MyObject. Мы могли бы иметь:

// - - - - MyObject_forward.hpp - - - - 
// This header is included by the code which need to know MyObject
// does exist, but nothing more.
template<typename T>
class MyObject ;

.

// - - - - MyObject_declaration.hpp - - - - 
// This header is included by the code which need to know how
// MyObject is defined, but nothing more.
#include <MyObject_forward.hpp>

template<typename T>
class MyObject
{
   public :
      MyObject() ;
   // Etc.
} ;

void doSomething() ;

.

// - - - - MyObject_implementation.hpp - - - - 
// This header is included by the code which need to see
// the implementation of the methods/functions of MyObject,
// but nothing more.
#include <MyObject_declaration.hpp>

template<typename T>
MyObject<T>::MyObject()
{
   doSomething() ;
}

// etc.

.

// - - - - MyObject_source.cpp - - - - 
// This source will have implementation that does not need to
// be shared, which, for templated code, usually means nothing...
#include <MyObject_implementation.hpp>

void doSomething()
{
   // etc.
} ;

// etc.

Вау!

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

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

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

Заключение

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

Но в тот день, когда у вас появятся круговые зависимости между шаблонированными объектами, не удивляйтесь, если ваша организация кода станет несколько более "интересной", чем обычная организация заголовков/кодов...

^_^