【问题标题】:Finding different ways to share C++ functions with different C++ applications [closed]寻找与不同 C++ 应用程序共享 C++ 函数的不同方法 [关闭]
【发布时间】:2015-05-15 21:49:38
【问题描述】:

我正在尝试寻找不同的方法在不同的应用程序中重用我的 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 

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

【问题讨论】:

  • 唯一可能的答案可能是:视情况而定!它依赖的东西很多,首先它很大程度上取决于你的用例,这对我们来说是未知的。它还取决于您是否希望“功能”成为类似实用程序的功能,是否可以预测它们的所有未来用途(通常您不能),未知应用程序是否将使用这些功能,以及未来如何未知应用程序可能想要使用您的函数,允许远程“调用”函数(即通过网络),以及许多其他事情。所以不幸的是,你的问题目前很广泛
  • 只做一个静态库,以后如果需要可以转成动态库。窗口服务对于库来说并没有多大意义,因为窗口服务通常提供完整的服务而不仅仅是一个功能,并且您必须具有某种进程间接口,例如管道、共享内存、共享数据文件或插座。
  • 完全内联的 C++ 头文件,可调用您构建为动态库的 C API。

标签: c++ dynamic static modular


【解决方案1】:

如果这些函数只会被您和/或您的同事“内部”调用(即它们不会暴露给无权访问您的源代码存储库的人)那么选项(D)就足够了。只需将 .cpp 和 .h 文件保存在源代码存储库的一个众所周知的子目录中,并让每个应用程序的项目文件在必要时引用它们。这很容易实现并为您提供最大的灵活性(因为每个项目都可以使用最适合其自身需求的不同编译器标志编译共享的 .cpp 文件,如果需要的话——使用一个库,您必须找出一个集合编译器标志适用于所有想要链接到库的应用程序,这并不总是很方便)。

如果您正在编写供公众使用的 API,OTOH,事情会变得有点复杂,因为在您向公众发布代码后,您将不再完全控制使用哪些版本以及在何处使用。在这种情况下,您必须根据您的用户是谁以及您认为他们最喜欢什么来做出决定。

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

【讨论】:

    【解决方案2】:

    一直都是选项 D(到处编译)——唯一的例外是与许多其他人(或封闭源代码)共享的独立库。

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

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

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-05-26
      • 2018-06-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多