Дизайн библиотеки: позволяет пользователю выбирать между «только заголовками» и динамически связаны?

Это зависит от операционной системы и компилятора. На Linux с очень недавним НКУ компилятор (версия 4.9) вы можете создать статический использование библиотеки межпроцедурная оптимизация времени соединения.

Это означает, что вы строите свою библиотеку с g++ -O2 -flto как во время компиляции, так и во время ссылки библиотеки, и что вы используете свою библиотеку с g++ -O2 -flto как во время компиляции, так и во время соединения вызывающей программы.

Это должно дополнить ответ @ Хорстлинга.

Вы можете создать статический или динамический библиотека. При создании статически связанных библиотек скомпилированный код для всех функций / объектов будет сохранен в файл (с расширением .lib в Windows). Во время связывания основного проекта (проекта с использованием библиотеки) эти коды будут связаны с вашим окончательным исполняемым файлом вместе с основными кодами проекта. Таким образом, конечный исполняемый файл не будет зависеть от времени выполнения.

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

При проектировании библиотеки нет необходимости выбирать между статическим или динамическим связыванием (или только заголовком), вы создаете несколько файлов проекта / make-файла, один для создания статического .lib, другой для создания пары .lib / .dll и распространяете обе версии, для пользователя на выбор. (Вам нужно будет использовать макросы препроцессора, подобные тем, которые предлагает @Horstling).

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

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

Вместо помещения встроенных функций в заголовочные файлы (с #include "foo.cpp" в вашем заголовке), вы можете изменить настройки makefile / project и добавить foo.cpp в список исходных файлов для компиляции. Таким образом, если вы измените какую-либо реализацию функции, вам не нужно будет перекомпилировать весь проект, и только foo.cpp будет перекомпилирован. Как я упоминал ранее, оптимизирующий компилятор будет по-прежнему выделять ваши маленькие функции, и вам не нужно об этом беспокоиться.

Если вы используете / проектируете предварительно скомпилированную библиотеку, вы должны рассмотреть случай, когда библиотека компилируется с другой версией компилятора для основного проекта. В каждой версии компилятора (даже в разных конфигурациях, таких как Debug или Release) используется разное время выполнения C (например, memcpy, printf, fopen, …) и время выполнения стандартной библиотеки C ++ (например, std :: vector).<>, std :: string, …). Эти различные реализации библиотек могут усложнять компоновку или даже создавать ошибки во время выполнения.

Как правило, всегда избегайте совместного использования объектов времени выполнения компилятора (структуры данных, которые не определены стандартами, такие как FILE *) между библиотеками, потому что несовместимые структуры данных приведут к ошибкам времени выполнения.

При связывании вашего проекта функции времени выполнения C / C ++ должны быть связаны с вашей библиотекой .lib или .lib / .dll или исполняемым файлом .exe. Сама среда выполнения C / C ++ может быть связана как статическая или динамическая библиотека (вы можете установить это в настройках makefile / project).

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

Существуют сценарии, в которых необходимо статически связывать среду выполнения C / C ++, и в этих случаях наилучшим подходом будет компилировать библиотеку с теми же настройками компилятора, что и в основном проекте, чтобы избежать проблем с компоновкой.

обоснование

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

1. универсальные шаблоны для определяемого пользователем параметра шаблона;

2. очень короткие удобные функции, когда встраивание дает значительный
   спектакль.

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

Заключение

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

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

Я знаком с компилятором Microsoft, который точно знает, что делает это с Visual Studio 2010 (если не раньше).

Шаблонный код обязательно будет иметь только заголовок: для создания экземпляра этого кода параметры типа должны быть известны во время компиляции. Нет способа встроить код шаблона в общие библиотеки. Только .NET и Java поддерживают создание экземпляров JIT из байт-кода.

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

Чтобы избежать «безумного времени компиляции», Microsoft Visual C ++ имеет функцию «предварительно скомпилированных заголовков». Я не думаю, что GCC имеет аналогичную функцию.

Длинные функции не должны быть встроены в любом случае.

У меня был один проект, в котором были биты только для заголовков, биты скомпилированной библиотеки и некоторые биты, которые я не мог решить, где они находятся. В итоге у меня были файлы .inc, условно включенные в .hpp или .cxx в зависимости от #ifdef. По правде говоря, проект всегда компилировался в режиме «max inline», поэтому через некоторое время я избавился от файлов .inc и просто переместил содержимое в файлы .hpp.

Можно ли получить лучшее из обоих миров?

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

Я недавно начал думать, что такой дизайн не очень хорош.

Так и должно быть. Библиотеки только для заголовков идеальны, потому что они упрощают развертывание: делает механизм повторного использования языка похожим почти на все остальные, что просто разумно делать. Но это C ++. Текущие инструменты C ++ по-прежнему полагаются на модели полувековой давности, которые устраняют важные степени гибкости, такие как выбор точек входа для импорта или экспорта на отдельном уровне. без быть вынужденным изменить исходный код библиотеки. Кроме того, C ++ не имеет надлежащей системы модулей и все еще полагается на прославленные операции копирования-вставки (хотя это лишь побочный фактор рассматриваемой проблемы).

На самом деле MSVC немного лучше в этом отношении. Это единственная крупная реализация, пытающаяся достичь некоторой степени модульности в C ++ (например, попытка Модули C ++). И это единственный компилятор, который фактически позволяет, например, следующие:

//// Module.c++
#pragma once
inline void Func() { /* ... */ }

//// Program1.c++
#include <Module.c++>
// Inlines or "vague" links Func(), whatever is better.
int main() { Func(); }

//// Program2.c++
// This forces Func() to be imported.
// The declaration must come *BEFORE* the definition.
__declspec(dllimport) __declspec(noinline) void Func();
#include <Module.c++>
int main() { Func(); }

//// Program3.c++
// This forces Func() to be exported.
__declspec(dllexport) __declspec(noinline) void Func();
#include <Module.c++>

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

GCC также принимает это (но порядок объявлений должен быть изменен), и у Clang нет никакого способа достичь того же эффекта без изменения источника библиотеки.