C ++: Недостатки написания целых классов в файлах заголовков для небольших проектов?

Question

Просто вопрос стиля ...

Я - независимый инди-разработчик, работающий сам по себе, и я разработал то, что, как мне сказали, является «плохой» привычкой писать целые классы в моих заголовках. Некоторые из известных мне преимуществ .h / .cpp - это то, что они позволяют разбивать код на части компиляции, которые не нужно будет перекомпилировать, пока они остаются неизменными. И позволяет отделить интерфейс от реализации.

Однако ни одна из этих вещей не приносит мне никакой пользы, так как я склоняюсь к тому, чтобы моя реализация была в месте, где я могу легко улучшить ее, изменить, прочитать. И время компиляции у меня почти мгновенное (2-4 секунды, 15, если я обновил SFML или Box2D до их последних версий, и их тоже нужно перекомпилировать)

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

Но в свете этого и вообще есть ли веская причина следовать «file.cpp» для каждой настройки «file.h» для небольшого проекта, где время компиляции и разделение интерфейса / реализации не являются приоритетами?

Answer 1

есть ли веская причина следовать «file.cpp» для каждой настройки «file.h» для небольшого проекта, где время компиляции и разделение интерфейса / реализации не являются приоритетами?

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

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

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

Answer 2

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

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

Однако не существует единого правила для всех размеров.А некоторые классы (особенно «маленькие»), вероятно, лучше всего размещать целиком в заголовке.

Answer 3

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

• одно определение правила
• тестирование

Если у вас есть только один файл cpp и пара дюжин заголовков, тогда вы можете позволить себе не обращать внимания на одно правило определения (при условии, что у вас есть охранники). Это может вас укусить, если вы однажды обнаружите необходимость перейти к компиляции / компоновке проекта в виде нескольких единиц перевода. Это может происходить не столь очевидными способами, например, желая позволить другим людям предоставлять библиотеку, которую они собирают, используя пару ваших заголовков. неявно (определяется внутри класса) или явно (с помощью ключевого слова) inline функции будут в порядке, но остерегайтесь других. Обычные правила для переменных и т.д ..

Для тестирования: иногда полезно иметь, по крайней мере, токен .cpp файл, который включает в себя .h и получает компиляции, просто чтобы вы получили раннее предупреждение, если содержимое одного заголовка не может «стоять отдельно», возможно, из-за чтобы забыть Если у вас есть тестовые файлы .cpp для каждого заголовка, то это убивает двух зайцев и т. Д. Если вы не хотите проводить тестирование на этом уровне и готовы оперативно устранять любые незначительные ошибки зависимостей, то можете забыть об этом.