Преимущества библиотек только заголовка

Question

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

Answer 1

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

Наличие библиотеки только заголовка и означает, что вам не нужно беспокоиться о разных платформах, где может использоваться библиотека.Когда вы отделяете реализацию, вы обычно делаете это, чтобы скрыть детали реализации, и распространять библиотеку в качестве комбинации заголовков и библиотек (GeneracodicCode, lib или файлов dll).Эти, конечно, должны быть составлены для всех разных операционных систем / версий, которые вы предлагаете поддерживать.

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

Конечно, это относится к Case-Case Case .Например, библиотеки только заголовка иногда увеличиваются Размер кода и время компиляции .

Answer 2

Преимущества библиотеки только заголовка:

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

  Недостатки библиотеки только заголовка:

  .

  • Большие объектные файлы. Каждый встроенный метод из библиотеки, используемого в некоторых исходных файлах, также получит слабый символ, определение вне строки в файле скомпилированного объекта для этого исходного файла. Это замедляет компилятор, а также замедляет линкер. Компилятор должен генерировать все это bloat, а затем линкер должен выфильтировать его.

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

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

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

Answer 3

Я знаю, что это старая поток, но никто не упомянул ABI интерфейсы или конкретные проблемы компилятора. Так я думал, что я бы.

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

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

Например, поставщики компилятора часто меняют свою реализацию STL между версиями. Если у вас есть функция в библиотеке, которая принимает STD :: Vector, то он ожидает, что байты в этом классе будут расположены в том, как они были устроены, когда библиотека была скомпилирована. Если в новой версии компилятора поставщик сделал улучшения эффективности в STD :: Vector, код пользователя видит новый класс, который может иметь другую структуру и передает эту новую структуру в вашу библиотеку. Оттуда все идет вниз ... Вот почему рекомендуется не пропускать объекты STL по границам библиотеки. То же самое относится и к типам времени работы C RUE (CRT).

Во время говорят о CRT, ваша библиотека и исходный код пользователя обычно должны быть связаны с тем же CRT. С Visual Studio, если вы создаете свою библиотеку, используя многопоточный CRT, но пользовательские ссылки против многопоточной отладки CRT, тогда у вас будут проблемы с ссылкой, потому что ваша библиотека может не найти символы. Я не могу вспомнить, какую функцию это было, но для Visual Studio 2015 Microsoft выполнила одну функцию CRT встроенным. Внезапно он был в заголовке, а не библиотека CRT, поэтому библиотеки, которые, как ожидали, найдут его по времени ссылки, больше не могли бы сделать, и эта сгенерированная ссылка на ошибки. Результатом заключалась в том, что эти библиотеки требуют перекомпиляции с Visual Studio 2015.

Вы также можете получить ошибки ссылки или странное поведение, если вы используете API Windows, но вы создаете с различными настройками Unicode к пользователю библиотеки. Это связано с тем, что API Windows имеет функции, которые используют строки Unicode или ASCII, так и макросы / определяющие, которые автоматически используют правильные типы на основе настроек Unicode проекта. Если вы проходите строку по границе библиотеки, это неправильный тип, то вещи разрываются во время выполнения. Или вы можете обнаружить, что программа не ссылается в первую очередь.

Эти вещи также верны для прохождения объектов / типов по границам библиотеки из других сторонних библиотек (например, вектором собственного сигнала или матрица GSL). Если библиотека 3-го вечеринки меняет свой заголовок между вами, вы составившей вашей библиотеки, и ваш пользователь собирает их код, то все будет сломаться.

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

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

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

Answer 4

Основная «преимущество» заключается в том, что для вас требуется доставить исходный код, так Вы получите отчеты об ошибках на машинах и с компиляторами, которые вы никогда не слышали о.Когда библиотека полностью шаблоны, у вас нет много выбора, но когда у вас есть выбор, только заголовок обычно плохо Технический выбор.(С другой стороны, конечно, заголовок только означает, что Вам не нужно документировать какую-либо процедуру интеграции.)