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