Существует ли стандартное соглашение #include для С++?

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

Бар.ч:

class Foo;

class Bar
{
    Foo * m_foo;
};

Бар.cpp:

#include "Foo.h"
#include "Bar.h"

Некоторые рекомендации:

• Каждый файл .cpp или .C включает все необходимые заголовки и не зависит от заголовков, включая другие связанные заголовки.
• Каждый файл .hpp или .h включает все свои зависимости и не зависит от включенных заголовков, включая другие связанные заголовки.

• Каждый заголовок обернут:

  #ifndef HEADER_XXX_INCLUDED
  #define HEADER_XXX_INCLUDED
  ...
  #endif /* HEADER_XXX_INCLUDED */
  

• Заголовки не включают друг друга в циклы

• Часто: существует один «заголовочный файл для всего проекта», например «config.h» или «.h», который всегда включается первым в любой файл .cpp или .C. Обычно это данные конфигурации, связанные с платформой, константы и макросы для всего проекта и т. д.

Это не обязательно «лучшая практика», но правила, которым я обычно следую:

• Заголовки, относящиеся к проекту, включаются как #include "..." и перед общесистемными заголовками, которые включаются как #include <...>.
• Заголовки, относящиеся к конкретному проекту, включаются в алфавитном порядке, чтобы гарантировать отсутствие случайного скрытого требования, в каком порядке они будут включены. Поскольку каждый заголовок должен включать в себя его зависимости, и заголовки должны быть защищены от многократного включения, вы должны иметь возможность включать их в любом порядке.

Ознакомьтесь с проектом крупномасштабного программного обеспечения C++ Джона Лакоса. Вот чему я следую (написано в качестве примера):

Интерфейс

// foo.h
// 1) standard include guards.  DO NOT prefix with underscores.
#ifndef PROJECT_FOO_H
#define PROJECT_FOO_H

// 2) include all dependencies necessary for compilation
#include <vector>

// 3) prefer forward declaration to #include
class Bar;
class Baz;
#include <iosfwd> // this STL way to forward-declare istream, ostream

class Foo { ... };
#endif

Выполнение

// foo.cxx
// 1) precompiled header, if your build environment supports it
#include "stdafx.h"

// 2) always include your own header file first
#include "foo.h"

// 3) include other project-local dependencies
#include "bar.h"
#include "baz.h"

// 4) include third-party dependencies
#include <mysql.h>
#include <dlfcn.h>
#include <boost/lexical_cast.hpp>
#include <iostream>

Предварительно скомпилированный заголовок

// stdafx.h
// 1) make this easy to disable, for testing
#ifdef USE_PCH

// 2) include all third-party dendencies.  Do not reference any project-local headers.
#include <mysql.h>
#include <dlfcn.h>
#include <boost/lexical_cast.hpp>
#include <iosfwd>
#include <iostream>
#include <vector>
#endif

Используйте только минимально необходимое количество включений. Бесполезное включение замедляет компиляцию.

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

class BogoFactory;

edit: Просто чтобы было ясно. Когда я говорил о минимальной сумме, я не имел в виду построение таких цепочек, как:

a.h
#include "b.h"

b.h
#include "c.h"

Если a.h нуждается в c.h, его, конечно же, необходимо включить в a.h, чтобы предотвратить проблемы с обслуживанием.

Есть несколько проблем с моделью #include, используемой в C/C++, главная из которых заключается в том, что она не выражает фактический граф зависимостей. Вместо этого он просто объединяет набор определений в определенном порядке, что часто приводит к тому, что определения идут в другом порядке в каждом исходном файле.

В общем, вам нужно знать иерархию включаемых файлов вашего программного обеспечения так же, как вы знаете свои структуры данных; вы должны знать, какие файлы включены откуда. Прочтите свой исходный код, узнайте, какие файлы находятся выше в иерархии, чтобы вы могли избежать случайного добавления включения, чтобы оно было включено «отовсюду». Когда вы добавляете новое включение, хорошенько подумайте: нужно ли мне включать это сюда? Какие еще файлы будут добавлены, когда я это сделаю?

Два соглашения (помимо уже упомянутых), которые могут помочь:

• Один класс == один исходный файл + один заголовочный файл с одинаковыми именами. Класс A идет в A.cpp и A.h. Шаблоны кода и фрагменты кода здесь хороши, чтобы уменьшить количество ввода, необходимого для объявления каждого класса в отдельном файле.
• Используйте шаблон Impl, чтобы избежать раскрытия внутренних членов в файле заголовка. Шаблон impl означает размещение всех внутренних членов в структуре, определенной в файле .cpp, и наличие только частного указателя с предварительным объявлением в классе. Это означает, что заголовочный файл должен будет включать только те заголовочные файлы, которые необходимы для его открытого интерфейса, а любые определения, необходимые для его внутренних элементов, не будут включены в заголовочный файл.

Основываясь на том, что сказал antti.huima:

Допустим, у вас есть классы A, B и C. A зависит (включает) B, а A и B зависят от C. Однажды вы обнаружите, что вам больше не нужно включать C в A, потому что B делает это за вас, и поэтому вы удаляете этот оператор #include.

Что произойдет, если в какой-то момент в будущем вы обновите B, чтобы больше не использовать C? Внезапно A сломался без уважительной причины.

В A.cpp всегда сначала включайте A.h, чтобы убедиться, что у A.h нет дополнительных зависимостей. Включите все локальные файлы (того же модуля) перед всеми файлами проекта перед всеми системными файлами, опять же, чтобы убедиться, что ничто не зависит от предварительно включенных системных файлов. Максимально используйте предварительные объявления. Используйте шаблон #indef/#define/#endif Если заголовок включен в A.h, вам не нужно включать его в A.cpp. Любые другие заголовки, необходимые A.cpp, должны быть явно включены, даже если они предоставлены другими файлами .h.

Организация файлов кода на C и C++: