Sty*_*Sty 2 c++ deployment c++17
我和我的团队目前正在开发一个基于C++ 14规范的软件.我们正在考虑std::variant在我们的代码中添加一些C++ 17特性(主要是s),但是我的主管不确定我们是否可以简单地将它们放在我们的代码中,使用适当的编译器构建然后发布它.
据我所知,如果我们为我们的目标平台预编译我们的应用程序并将它们作为可执行文件提供,这应该没有任何区别,但我还没有真正处理过向客户部署软件,所以我不确定是否我在这里忽略了任何东西(比如我们还必须根据Windows的C++可再发行组件供应).
作为背景信息:我们的软件基于Qt,因此可以部署到所有主要的桌面操作系统.我们主要在Windows环境中工作,对于大多数测试目的,我们目前正在使用MSVC2017进行编译.
我们在技术上也计划发布一个SDK /库,以便于与我们的应用程序的网络部分连接,这也可能受益于C++ 17的功能.我假设愿意使用这个SDK的开发人员将被迫使用符合C++ 17的构建环境,即使C++ 17的功能几乎封装在库中而不是暴露在头文件中 - 是正确？
答案是(像往常一样)"它取决于".
如果使用的C++ 17功能完全是从模板构建的,并且C++ 17类型/功能未在SDK标头中公开,那么这绝对应该可以正常工作,因为模板将被实例化并包含在库的本机中通过代码的编译器.
如果C++ 17功能依赖于某些运行时库支持,但未在SDK中公开,那么您只需要发布该运行时库或以其他方式使其可用.
无论您是否使用C++ 17功能,您的SDK用户都应使用完全相同的C++环境(如果可能,包括版本),因为无法保证C++版本之间的ABI兼容性,也不保证不同版本之间的ABI兼容性相同的编译器.如果您使用MSVC++ 2017,您的SDK用户还必须使用MSVC++ 2017或其他明确记录的环境以与MSVC++ 2017 ABI兼容.(因此,不应该询问这是否有效,您应该询问要求SDK用户使用哪种版本的MSVC++是合理的,这是我无法回答的问题.)
在所有情况下,只要您提供所需的运行时库(即使您可能需要更改自己运行的运行时库),那么不打算使用SDK的最终用户应该没有问题.
| 归档时间： |
|
| 查看次数： |
128 次 |
| 最近记录： |