Linking: Статические против динамических

Question

В моем приложении у меня есть 3 основных частей:

• Exe: исполняемый файл
• Lib_A: библиотека содержит класс синглтон и базовый класс для некоторых расчетов будет использовать в одноточечно класс
• Lib_B: библиотека содержит ряд классов, производных от основания в Lib_A

причина, по которой у меня есть производные классы в Lib_B, я хотел бы для компиляции Lib_B во время выполнения из Exe. Мне нужно генерировать производные классы во время вычислений, не прерывая всю систему. Это слишком важно для меня. Это означает, что вначале я могу сказать, что Lib_B1 динамически загружен, также я могу скомпилировать другие версии Lib_B как Lib_B2, Lib_B3, Lib_B4 и т. Д. И загружать их динамически. Все библиотеки Lib_Bx будут иметь функции точки входа для экспорта классов в них.

Так принимая следующие факты во внимание:

• Во время выполнения будет различное количество файлов, разделяющих один и тот же Lib_A.
• Приложение должно работать в Windows и Linux. Таким образом, частичная кросс-платформенная проблема.
• Я собираюсь использовать некоторые библиотеки, такие как TBB, Boost, Qt, которые могут иметь свои собственные библиотеки, как tbb.dll и т.д.

Каковы плюсы и минусы статически или динамически связывая в Lib_A против обоих Exe и Lib_Bx? Как повлиять на производительность, размер системы и т. Д.? Есть ли какие-либо опасные или трудные ситуации, которые я могу получить, кроме того, для каждой ОС мне нужно использовать один и тот же компилятор для Exe, Lib_A и Lib_Bx.

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

Большое спасибо.

Answer 1

Из того, что я понимаю из вашего описания проекта, вы должны динамически связывать Lib_A: если вы связываете Lib_A статически с каждой из ваших общих библиотек Lib_Bx, вы будете дублировать x раз код Lib_A и статические переменные.

Скажем, если у вас есть класс в Lib_A, которые имеют вид:

class BaseKlass 
{ 
    static int instance_count; 
    ... 
}; 

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

Вы могли бы быть укушенным более тонкие проблемы с виртуальными таблицами, или RTTI (dynamic_cast) и т.д.

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

Boost.python позволяет создавать модули python (динамические библиотеки), которые должны быть загружены в один и тот же процесс. Каждый модуль python, созданный с помощью boost.python, если они должны взаимодействовать вместе на уровне C++, например, вызывая класс B в модуле из класса A в другом модуле, должен динамически связываться с boost.python lib, чтобы избежать проблем.

Answer 2

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

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

Возможно, проще использовать один и тот же компилятор для Windows и Linux, но вам определенно не нужно использовать один и тот же компилятор.

До тех пор, пока вы придерживаетесь портативных библиотек, наибольшая разница между Windows и Linux обычно является системой сборки. Некоторые разработчики поддерживают полностью отдельные системы сборки, но есть много кросс-платформенной системы сборки, такой как cmake.

Answer 3

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

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

Если вы действительно хотите взаимодействовать с компилируемыми модулями во время выполнения независимо от платформы, тогда вам лучше использовать нейтральный и нейтральный интерфейс платформы, например CORBA. Затем вещи, скомпилированные и запущенные в вашем ящике Linux и ящике Windows, могут взаимодействовать друг с другом и компилировать новых членов для присоединения к банде.

Answer 4

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

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