динамический — поиск различных способов обмена функциями C ++ с различными приложениями C ++
Я пытаюсь найти разные способы повторного использования моих функций C ++ в разных приложениях. Скажем, например, у меня есть следующие функции:
Function A(){} // this will do a complex math operation
Function B(){} // this will load a complex shape file
Function C(){} // Print the results.
Мне нужно использовать вышеупомянутые 3 функции в 3 разных программах на C ++. Они полностью независимы, и я пытаюсь понять, как лучше всего использовать их во всех моих приложениях, а не писать один и тот же код 3 раза.
Я думаю о следующих вариантах:
Option A: Writing static library
Option B: Writing dynamic library
Option C: Windows Services
Option D: Same code and compile everywhere
Есть ли другие варианты? Или какой будет лучший вариант?
Решение
Если функции будут называться «собственными силами» только вами и / или вашими коллегами (то есть они не будут видны людям, не имеющим доступа к вашему хранилищу исходного кода), тогда option ( Г) достаточно. Просто храните файлы .cpp и .h в одном хорошо известном подкаталоге вашего репозитория исходного кода и по необходимости обращайтесь к файлу проекта каждого приложения. Это просто реализовать и дает вам максимальную гибкость (так как каждый проект может компилировать совместно используемые файлы .cpp с различными флагами компилятора, которые лучше всего соответствуют его собственным потребностям, если это необходимо — с библиотекой, которую вы должны выяснить, один набор флагов компилятора, которые будут работать для всех приложений, которые хотят соединиться с библиотекой, что не всегда удобно).
Если вы пишете API для публичного использования, OTOH, все становится немного сложнее, так как после публикации кода для публики вы больше не будете полностью контролировать, какие версии используются и где. В этом случае вам придется принимать решение, основываясь на том, кто ваши пользователи и что, по вашему мнению, им будет наиболее удобно.
Вариант C, вероятно, может быть отброшен, так как он избыточен для такого рода вещей и несет ответственность за привязку вашего кода к конкретной ОС без каких-либо компенсационных преимуществ.
Другие решения
Это вариант D (компилировать везде) полностью — с единственными исключениями, являющимися автономными библиотеками, которые используются многими, многими другими людьми (или с закрытым исходным кодом).
- Это значительно облегчает управление выпусками, потому что на самом деле их нет — каждая копия библиотеки может обновляться независимо — когда это удобно.
- Это облегчает отладку каждого проекта в библиотеке с конкретной версией используемой библиотеки.
- Это дает вам возможность настроить библиотеку для каждого проекта — но используйте эту возможность разумно, чтобы минимизировать сложность объединения.
Этот выбор не зависит от того, собираете ли вы библиотеку в отдельный двоичный пакет или нет, как часть процесса сборки.
Я бы порекомендовал использовать что-то вроде git-submodules для управления кодом — за исключением того, что особенность git-submodules является наполовину запеченной.