C ++ 11是否解决了在动态/共享库边界之间传递std lib对象的问题？（即dll等）？

我对C ++的主要抱怨之一是在实践中将标准库对象传递到动态库（例如dll / so）边界之外有多么困难。

std库通常是仅标头的。这非常适合进行一些很棒的优化。但是，对于dll，它们通常是用不同的编译器设置构建的，这可能会影响std库容器的内部结构/代码。例如，在MSVC中，一个dll可能会在打开迭代器调试的情况下构建，而另一个dll会在关闭调试器的情况下构建。这两个dll可能会遇到传递标准容器的问题。如果std::string在界面中公开，则不能保证客户端使用的代码与std::string库的完全匹配std::string。

这导致难以调试问题，头痛等。您要么严格控制组织中的编译器设置以防止出现这些问题，要么使用没有这些问题的更简单的C接口。或向您的客户指定他们应使用的预期编译器设置（如果另一个库指定了其他编译​​器设置，则很糟糕）。

我的问题是C ++ 11是否试图做任何事情来解决这些问题？

您是正确的，在任何公共C ++ API中最好避免任何STL（实际上，任何来自模板库的第三方库中的任何东西）。您还希望遵循http://www.ros.org/reps/rep-0009.html#definition上的一长串规则，以禁止ABI破坏，这使得对公共C ++ API进行编程变得很繁琐。

关于C ++ 11的答案是否定的，这个标准并没有解决这个问题。更有趣的是为什么不呢？答案是因为C ++ 17非常令人触动，要实现C ++模块，我们需要导出的模板才能工作，为此，我们需要LLVM类型的编译器（例如clang），可以将完整的AST转储到光盘，然后在任何大型C ++项目中都进行与调用者相关的查找，以处理许多违反ODR的情况-顺便说一句，它包含许多GCC和ELF代码。

最后，我看到了许多MSVC仇恨和亲GCC评论。这些都是错误的信息-ELF上的GCC从根本上来说是无法恢复的，无法生成有效且正确的C ++代码。造成这种情况的原因很多，但我将快速举一个例子：ELF上的GCC无法安全地生成使用Boost.Python编写的Python扩展，其中多个基于Boost.Python的扩展已加载到Python中。这是因为ELF带有全局C符号表的设计完全无法通过设计来防止ODR违反导致段错误，而PE和MachO以及实际上提出的C ++模块规范都使用了每个模块的符号表-顺便说一句，这也意味着极大的进程初始化时间。还有很多其他问题：请参阅我最近在回答的StackOverflow例如，https： //stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error/14364055#14364055在ELF上从根本上无法修复C ++异常引发。

最后一点：关于互操作不同的STL，这对于许多试图将紧密集成到某些STL实现中的第三方库混合在一起的大型企业用户来说是一个很大的痛苦。唯一的解决方案是C ++处理STL互操作的新机制，当您使用STL互操作时，您也可能会修复编译器互操作，因此您可以（例如）混合使用MSVC，GCC和clang编译的目标文件，并且所有这些都可以正常工作。我会观察C ++ 17的成果，然后看看接下来几年会发生什么-如果什么都做不到，我会感到惊讶。

规范从未出现过此问题。这是因为它具有称为“一个定义规则”的概念，该概念要求每个符号在运行的过程中都具有一个唯一的定义。

Windows DLL违反了此要求。这就是为什么存在所有这些问题的原因。因此，由Microsoft来解决它，而不是由C ++标准化委员会来解决。Unix从未遇到过这个问题，因为共享库在那里的工作方式不同，并且默认情况下符合一个定义规则（您可以明确地打破它，但是显然，只有在您知道自己负担得起并且需要挤出几个额外的周期的情况下，才这样做）。

Windows DLL违反一个定义规则，因为：

• 它们在静态链接时间内使用哪个符号的硬库进行硬编码，并在定义符号的库中静态解析符号。因此，如果在多个共享库中生成相同的弱符号，并且与在单个进程中使用的库相比生成的弱符号，则动态链接程序将没有机会合并这些符号。通常，此类符号是模板实例的静态成员或类标记，因此在不同DLL中的代码之间传递实例时会引起问题。
• 他们在编译过程中已硬编码是否将符号从动态库中导入。因此，静态链接到某个库的代码与动态链接到同一库的代码不兼容。

Unix使用ELF格式导出会隐式导入所有导出的符号，以避免出现第一个问题，并且直到静态链接时间才避免静态和动态解析的符号之间的区别，从而避免出现第二个问题。

另一个问题是编译器标志。对于由多个编译单元组成的任何程序都存在该问题，而不必涉及动态库。但是，在Windows上情况更糟。在Unix上，无论是静态链接还是动态链接都没有关系，没有人以静态方式静态链接标准运行时（在Linux中甚至可能是非法的），并且没有特殊的调试运行时，因此一个构建就足够了。但是Microsoft实现静态和动态链接，调试和发布运行时以及其他一些选项的方式意味着它们引起了所需库变体的组合爆炸。再次是平台问题，而不是C ++语言问题。

没有。

替换标头系统还有很多工作要做，该功能称为模块，可能会对此产生影响，但肯定不会很大。