实际上，动态库只有两个主要的陷阱，在那里你 * 可以 * 轻易地打破C++标准中的假设，使它不匹配abstract machine：

• 违反“一个定义”规则：例如，你已经设法动态链接两个库，它们具有相同符号的不同实现;出于某种原因，每个人都有首选的 * 本地 * 链接，并且根据谁调用，使用不同的实现。C++规范仍然告诉你允许做什么，即使编译器，链接器和动态加载器可以很容易地配置为违反规则。

在这种情况下，默认情况下，例如，在Linux系统上使用ld-linux + gcc + ld，对 all 符号具有公共可见性，这意味着 all 符号在运行时由动态加载器解析，这实际上符合抽象机器的描述。
不幸的是，出于性能原因，这种默认设置并不可取。限制符号的可见性是允许最基本形式的内联优化的先决条件。

• 在非预期时间加载和卸载库：这意味着指针（指向代码和数据段）可以在任意时间变得（或保持）无效，这与抽象状态机完全不匹配。

在这两种情况下，作为开发人员，您仍然有责任确保您处于抽象机器的范围内，并且不会导致任何与之相矛盾的可观察行为。
理论就这么多了。
事实上，在这两种情况下，大多数动态库实际上甚至不 * 尝试 * 作为一个整体，好像系统/进程符合C抽象机。
相反，C只被期望在每个动态库中完全发挥作用，而整个外部接口完全意识到动态链接，符号可见性等，并避免任何可能暴露边界上未定义行为的C++功能。每个库- * 独立 * -遵循抽象机器。