我一直在研究＆＃34;更新＆＃34;的一些功能。 C ++标准（C ++ 11和C ++ 14），这让我想到了什么。我目前正在为我的项目使用VC ++ 2008编译器（出于各种原因），这意味着我可以访问的最新标准是C ++ 03和TR1。 TR1有一些不错的东西，但C ++ 11和C ++ 14中的功能很不错。
我的问题是：我是否可以使用更新的编译器（比如MSVC2012或2013）使用更新的C ++ 11和C ++ 14功能构建库或DLL然后链接来构建一些代码在我的项目中运行＆＃39; 08编译器？
我能想到的唯一不会工作的东西就是我必须在我的编译器项目包含的标题中拥有C ++ 11或C ++ 14功能。然而，只要一切都是新的＆＃34;隐藏在我的界面后面，不应该这样做吗？
答案 0 :(得分：6)
是的，但它会变得丑陋..因为ABI不兼容，你必须要去＃34; extern "C" {}＆＃34; ABIness。
这意味着你根本无法传递C ++对象......就像我说的那样痛苦。这也意味着它必须是一个DLL，因为你无法在静态库中链接另一个ABI。
如果它值得在C API中包装一个DLL只是为了使用一些新功能，我会建议只是升级整个项目。
我差点忘了，您可能无法链接导入库，因此您必须拥有一些使用LoadLibrary，GetProcAddress和FreeLibrary的代码（我提到这是丑陋/痛苦吗？）。
答案 1 :(得分：1)
不幸的是，MSVC无法实现您的目标。他们故意破坏MSDN documentation中所述的每个主要版本的二进制兼容性：
要启用新的优化和调试检查，C ++标准库的Visual Studio实现会故意破坏从一个版本到下一个版本的二进制兼容性。因此，当使用C ++标准库时，使用不同版本编译的目标文件和静态库不能混合在一个二进制文件（EXE或DLL）中，并且C ++标准库对象不能在二进制文件之间传递。使用不同的版本编译。这种混合会发出有关_MSC_VER不匹配的链接器错误。 （_MSC_VER是包含编译器主要版本的宏 - 例如，Visual Studio 2013中的Visual C ++为1800.）此检查无法检测DLL混合，并且无法检测涉及Visual C ++ 2008或更早版本的混合。
您的选择是仅传递POD类型，或实现COM接口以在使用不同版本的VC编译器编译的DLL之间互操作，这两者都不是特别适合。
我的建议是，如果您必须坚持使用VS2008来处理某些遗留应用程序，请将其吸收并处理它支持的功能集（至少您有TR1）。对于较新的项目，请尝试与您的团队讨论使用较新版本的VC。