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

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

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

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

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

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

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

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

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

1. нет необходимости писать и синхронизировать заголовки и источники.

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

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

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

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

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

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

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

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

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

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

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

• общие:
• заголовок переадресации: в случае шаблонов и т. д. Этот файл получает объявления о переадресации, которые появятся в заголовке.
• заголовок: этот файл включает заголовок пересылки, если таковой имеется, и объявляет все, что я хочу быть общедоступным (и определяет класс...)
• Private:
• 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

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

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

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

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

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

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

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

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

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

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