Сокращение Декларации и Реализации в файл HPP

Question

Я прочитал несколько статей о необходимости / применимости / практичности сохранения заголовков в C ++, но я не могу найти где-нибудь вескую причину, почему / когда вышеупомянутое должно или не должно быть сделано. Я знаю, что boost использует файлы .hpp для доставки функций шаблона конечным пользователям без необходимости в связанном файле .cpp, и эта мысль частично проистекает из просмотра этого кода. Похоже, что это был бы удобный способ доставки отдельных файловых модулей, скажем, нового виджета Wt или Qt (все еще придерживаясь одного класса в соответствии с соглашением .h).

Однако существуют ли какие-либо негативные технические реализации для предоставления кому-то одного файла .hpp с объявлением заголовка и реализацией, если у вас нет проблем с доступом к реализации (скажем, в контексте OSS). Имеет ли это для примеров какие-либо негативные последствия с точки зрения компилятора / компоновщика?

Буду признателен за любые мнения или мнения по этому поводу.

Answer 1

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

Неправильный глагол: это не «без необходимости », это «без способности ».

Если бы Boost мог, они бы разделили свои библиотеки на заголовки и файлы реализации. На самом деле, они делают это везде, где это возможно.

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

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

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

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

Answer 2

С шаблонами у вас нет реального выбора.Теоретически, export позволяет вам отделить интерфейс от реализации, но только один компилятор (Comeau) действительно поддерживает это ¹ , и он удаляется из C ++ 0x.

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

¹ Хотя это в основном интерфейс компилятора EDG, который действительно поддерживает еготак что другие компиляторы на основе EDG, такие как Intel, также в некоторой степени поддерживают export, хотя они этого не документируют, поэтому вы не можете сильно зависеть от них.

Answer 3

Основным негативным аспектом библиотек .hpp-only является то, что они не могут ссылаться на предварительно скомпилированный модуль.Весь код, присутствующий в .hpp, и, следовательно, весь код в библиотеке, должен быть добавлен в ваше приложение.Это увеличивает размер двоичного файла и создает избыточные двоичные файлы в такой системе, которая использует библиотеку более одного раза.