C++ код в заголовочных файлах

день, когда кодеры C++ соглашаются на Путь, ягнята лягут со львами, палестинцы обнимут израильтян, а кошкам и собакам будет позволено пожениться.

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

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

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

то, что может информировать Вас коллега, - это представление о том, что большинство кода C++ должны быть шаблонными, чтобы обеспечить максимальную удобство использования. И если он шаблонный, то все должно быть в заголовочном файле, чтобы клиентский код мог его увидеть и создать экземпляр. Если это достаточно хорошо для Boost и STL, это достаточно хорошо для нас.

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

Я думаю, что ваш коллега умный и правильный.

полезные вещи, которые я нашел, что положить все в заголовки это:

1. Не нужно писать & заголовки синхронизации и источники.

2. структура проста, и никакие круговые зависимости не заставляют кодер делать" лучшую " структуру.

3. портативный, легко встроенный в новый проект.

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

1. изменение исходного файла, скорее всего, изменит файлы заголовков, что приведет к повторной компиляции всего проекта.

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

наконец, я просто хочу поддержать вашего сотрудника, просто в моем личном представлении.

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

помните: глупая последовательность-это Хобгоблин маленьких умов.

Как правило, при написании нового класса я помещаю весь код в класс, поэтому мне не нужно искать его в другом файле.. После того, как все работает, я разбиваю тело методов в файл cpp, оставляя прототипы в файле hpp.

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

я лично использую 4 типа файлов в моем C++ проекты:

• общие:
• заголовок пересылки: в случае шаблонов и т. д. Этот файл получает объявления пересылки, которые появятся в заголовке.
• заголовок: этот файл включает заголовок пересылки, если таковой имеется, и объявляет все, что я хочу быть общедоступным (и определяет класс...)
• личные:
• Private header: этот файл является заголовком, зарезервированным для реализации, он включает заголовок и объявляет вспомогательные функции / структуры (например, для Pimpl или предикатов). Пропустите, если это не нужно.
• исходный файл: он включает собственный заголовок (или заголовок, если нет частного заголовка) и определяет все (не шаблон...)

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

это означает, что я предпочитаю прямое объявление над #include директива в моих заголовках, когда я могу уйти с ними.

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

говоря в целом:

// example_fwd.hpp
// Here necessary to forward declare the template class,
// you don't want people to declare them in case you wish to add
// another template symbol (with a default) later on
class MyClass;
template <class T> class MyClassT;

// example.hpp
#include "project/example_fwd.hpp"

// Those can't really be skipped
#include <string>
#include <vector>

#include "project/pimpl.hpp"

// Those can be forward declared easily
#include "project/foo_fwd.hpp"

namespace project { class Bar; }

namespace project
{
  class MyClass
  {
  public:
    struct Color // Limiting scope of enum
    {
      enum type { Red, Orange, Green };
    };
    typedef Color::type Color_t;

  public:
    MyClass(); // because of pimpl, I need to define the constructor

  private:
    struct Impl;
    pimpl<Impl> mImpl; // I won't describe pimpl here :p
  };

  template <class T> class MyClassT: public MyClass {};
} // namespace project

// example_impl.hpp (not visible to clients)
#include "project/example.hpp"
#include "project/bar.hpp"

template <class T> void check(MyClass<T> const& c) { }

// example.cpp
#include "example_impl.hpp"

// MyClass definition

Спаситель здесь что в большинстве случаев передний заголовок бесполезен: необходим только в случае typedef или template и так же заголовок реализации;)

Если этот новый способ реально Путь, мы могли бы работать в другом направлении в наших проектах.

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

также мы используем "непрозрачный указатель"-шаблон когда это применимо.

с этими практиками мы можем делать более быстрые сборки, чем большинство наших сверстников. И да... изменение кода или членов класса не приведет к огромным перестроениям.

, чтобы добавить больше удовольствия вы можете добавить .ipp файлы, содержащие реализацию шаблона (который включается в .hpp), а .hpp содержит интерфейс.

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

Я лично делаю это в заголовочных файлах:

// class-declaration

// inline-method-declarations

мне не нравится смешивать код для методов с классом, так как я нахожу боль, чтобы быстро искать вещи.

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

выполнение методов в классе допустимо... но от readablilty точка зрения мне не нравится. Размещение методов в заголовке означает, что, когда это возможно, они будут вставлены.

ИМХО, у него есть заслуга, только если он делает шаблоны и / или метапрограммирование. Существует множество причин, уже упомянутых, что вы ограничиваете заголовочные файлы только объявлениями. Они просто такие... заголовки. Если вы хотите включить код, вы компилируете его как библиотеку и связываете его.

Я поместил всю реализацию из определения класса. Я хочу иметь комментарии doxygen из определения класса.

разве это не зависит от сложности системы и внутренних соглашений?

на данный момент я работаю над симулятором нейронной сети, который невероятно сложен, и принятый стиль, который я должен использовать:

определения классов в classname.h
Код класса в classnameCode.h
исполняемый код класса.cpp

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

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