libc ++是否保持内部状态？

Question

libc ++是否维护一个进程范围的内部状态，其中代码的一部分中发生的动作可以通过调用std :: *类（例如std :: set）来影响代码的某些远程部分？为了更具体一点，我发现过这样的崩溃（仅显示堆栈跟踪的顶部）：

std::__1::__tree<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__insert_unique(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 156, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)

修复程序是升级不直接参与崩溃的库，以纠正C ++ ABI问题。我很惊讶ABI问题可能会对原因造成影响，并想知道标准库本身是否有某些状态已损坏？

Answer 1

C ++不提供受保护的环境。如果代码的任何部分做了一些禁止的事情（例如删除一个对象两次，写下数组的限制......）那么代码的任何其他地方都可以立即或长时间后做任何事情。

实际上，问题通常是错误只是显然没有造成任何伤害，因为程序（显然）只是起作用。

关于违反ABI的错误是非常低级别的（例如，可能需要机器代码来保留某个寄存器而不是这样）并且没有什么可以让您感到惊讶。欢迎来到“未定义的行为”地狱。

在特定的std::set和std::map中，已知某些实现依赖于标记，因此覆盖全局变量会影响以后创建的地图和集合。

C ++中的几乎所有内容都依赖于动态分配的内存，违反ABI的程序可能会破坏与之相关的数据结构，并且这些效果可能会在以后显示数百万条执行的指令（例如，当损坏的空闲块被重新分配给其他内容时）。