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

Question

Мой личный стиль в C ++ всегда заключался в том, чтобы помещать объявления классов во включаемый файл и определения в файл .cpp, очень похоже на то, как указано в Ответ Локи на Заголовочные файлы C ++, Разделение кода . По общему признанию, одна из причин, по которой мне нравится этот стиль, вероятно, связана со всеми годами, которые я потратил на кодирование Modula-2 и Ada, оба из которых имеют похожую схему с файлами спецификаций и файлами тела.

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

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

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

Answer 1

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

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

Также мы используем «непрозрачный указатель» - образец , когда это применимо.

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

Answer 2

Я думаю, что абсолютно абсурдно помещать ВСЕ ваши определения функций в заголовочный файл. Зачем? Потому что заголовочный файл используется как интерфейс PUBLIC для вашего класса. Это за пределами «черного ящика».

Когда вам нужно взглянуть на класс, чтобы узнать, как его использовать, вы должны посмотреть файл заголовка. Заголовочный файл должен содержать список того, что он может делать (закомментированный для описания деталей использования каждой функции), и он должен включать список переменных-членов. Он НЕ ДОЛЖЕН включать КАК реализована каждая отдельная функция, потому что это лишняя информация, загруженная с лодки, и только загромождающая файл заголовка.

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

Кстати, Тед, вы смотрели на этом форуме недавний вопрос о привязке Ada к библиотеке CLIPS, которую вы написали несколько лет назад и которая больше не доступна (соответствующие веб-страницы теперь закрыты). Даже если она сделана для старой версии Clips, эта привязка может стать хорошим примером для тех, кто хочет использовать механизм вывода CLIPS в программе Ada 2012.

Answer 7

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