Question

我正在尝试找到在不同应用程序中重用我的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个不同的C ++程序中使用上述3个函数。它们是完全独立的，我试图看看在我的所有应用程序中使用它们的最佳方法是什么，而不是编写相同的代码3次。

我正在考虑以下选项：

      Option A: Writing static library 
      Option B: Writing dynamic library 
      Option C: Windows Services 
      Option D: Same code and compile everywhere

还有其他选择吗？或者什么是最好的选择？

Answer 1

如果仅在内部调用这些功能＆＃34;您自己和/或您的同事（即他们不会接触到无法访问您的源代码存储库的人），那么选项（D）就足够了。只需将.cpp和.h文件保存在源代码存储库的一个众所周知的子目录中，并让每个应用程序的项目文件根据需要引用它们。这很容易实现，并为您提供最大的灵活性（因为每个项目都可以使用不同的编译器标志编译共享.cpp文件，如果有必要，最适合自己的需要 - 使用库，您必须找出一个单组编译器标志，适用于所有想要链接到库的应用程序，这并不总是很方便。

如果您正在为公众消费而写一个API，那么事情会变得复杂一些，因为在您向公众发布代码后，您将无法完全控制哪些版本被使用以及哪些版本被使用。在这种情况下，您必须根据您的用户以及您认为他们最满意的内容做出决定。

选项C可能会被抛弃，因为它对这类事情来说太过分了，并且会带来将代码绑定到特定操作系统而没有补偿优势的惩罚。

Answer 2

它是选项D（在任何地方编译） - 唯一的例外是与许多其他人（或闭源）共享的独立库。

这使得管理版本变得更加容易，因为实际上没有任何版本 - 库的每个副本都可以独立更新 - 只要方便。
这使得每个项目都可以使用正在使用的库的特定版本轻松调试到库中。
这使您可以选择为每个项目自定义库 - 但明智地使用此功能以最小化合并复杂性。

此选择与您是否将库构建为单独的二进制包作为构建过程的一部分无关。

我建议使用类似git-submodules的东西来管理代码 - 除了the git-submodules feature is kind of half-baked。

寻找与不同C ++应用程序共享C ++函数的不同方法

2 个答案: