如何处理跨执行边界的 libstdc++ 抛出异常答案

【问题标题】：How to deal with libstdc++ throwing exception across execution boundaries如何处理跨执行边界的 libstdc++ 抛出异常
【发布时间】：2019-10-28 17:00:11
【问题描述】：

根据THIS page，很多 std::string 函数可以在 libstdc++ 实现中抛出异常。我无法更改 libstdc++ 的实现，而且切换到其他库的成本太高。我目前的目标是使大量使用 std::string 的代码符合 SEI CERT C++ 编码标准。我的问题是：

如何解决此问题以使 libstdc++ 不会跨越执行边界？
我认为无论我切换到哪个标准库实现，我最终都可能会遇到这个问题，因为从库中抛出异常是一种常见且可以说是合理的做法。那是否意味着我将永远面临这样的问题？是在实践中如此微不足道，以至于人们并不真正关心，还是人们使用异常来处理错误只是一种权衡？

谢谢！

【问题讨论】：

“执行边界”可能是上述编码标准中的一个术语，但它并不是在 C++ 上下文中经常使用的术语。我想到了另外两件事：是的，在正常情况下你不能逃避异常，同时仍然编写惯用的 C++。但是，如果中止是可以接受的，您可能能够重建一个标准库来执行此操作而不是抛出。我似乎记得至少 STLport 曾经有过这样的选择。
“执行边界”是什么意思？如果您的意思是 ABI 边界，那么让异常跨越 ABI 边界可能是未定义的行为（可能是实现定义的 - 检查您的工具链文档）。
@RichardCritten：不，不是。有很多支持异常的 ABI，例如适用于 C++ 的 Itanium ABI。
@MSalters 那么异常没有跨越 ABI 边界。
@RichardCritten：那么，我没有发现您的“ABI 边界”比问题中的“执行边界”更能提供信息。

标签： c++ exception

【解决方案1】：

C++ 编码标准已经禁止您跨执行边界传递非标准布局类型，std::string 就是这样一种类型。异常部分不会使问题变得更糟。

通常选择的合理解决方案是在您的程序中不设置“执行边界”。相反，您使用单个 ABI 和单个标准库来编译整个程序。

如果您有插件机制，您通常会为该插件接口创建一个狭窄的 API。在这个界面上，您甚至可以坚持使用 C ABI，因此插件作者不限于 C++。由于这是一个 C ABI，因此您要确保您的 C++ 异常不会被抛出到插件中。 std::string 在这里不是问题，您可以使用 char const*。

【讨论】：

感谢您的回答。 “您使用单个 ABI 和单个标准库编译整个程序。”您能否详细说明如何执行此操作？假设我的程序形成一个 ABI，标准库形成另一个 ABI，那么只要我在程序中使用那些 std::string 函数，异常就会跨越 ABI 边界，对吧？您的意思是我需要将标准库源代码与我的程序源代码一起编译吗？谢谢。
@james：根据定义，标准库是 C++ 实现的一部分，必须与编译器匹配。您不需要专门编译它，这已经为您完成了。为了完整起见，请注意在 Linux 上的情况稍微有点混乱，因为常见的实现依赖于 C 库的操作系统版本。但这当然不会影响std::string 或例外情况。
感谢@MSalters。我可能对标准库的工作方式有一些误解。那是因为 std::string 仅在标头中实现，因此一旦包含，它就成为我实现的一部分，正如您所说，编译器已经为我完成了。那些在 libstdc++.so 或 libstdc++.a 中预编译成二进制形式的函数呢？当与 libstdc++ 链接时，如果这些函数中的任何一个抛出，会导致异常跨越 ABI 边界吗？例如异常从 libstdc++.so 跨到 myprog.exe？
@james：你似乎对术语感到困惑。在 C++ 中，“实现”是指预处理器、编译器、链接器和标准库——基本上是 C++ 标准描述的部分。它非常不是你的程序。整个实现必须按照标准运行，标准说std::string 有效，异常有效。整个“ABI 边界”混乱只有在您开始混合编译器时才真正开始，因此不清楚“ 实现”是什么意思。
但是有没有可能让标准库在一个编译器中编译，而我自己的代码在另一台机器上使用不同的编译器编译？当该标准库中的函数抛出异常时，该异常会跨越 ABI 边界吗？