函数范围的静态变量如何导致与共享库中函数代码的未来使用不兼容

Question

HIC++ Coding 标准的规则 3.3.1 限制使用具有静态存储持续时间的变量，即使它们是在块范围内声明的：

具有静态存储持续时间的块作用域对象的初始化顺序是明确定义的。但是，此类对象的生命周期在程序终止时结束，这可能与代码的未来使用不兼容，例如作为共享库。

Application const & theApp()  
{  
  static  Application  app; // Non-Compliant  
  return  app;  
}

问题是会发生什么不兼容问题。

UPD。在我从@Employed-Russian 得到合理的评论后，我意识到需要进行一些澄清。我可以想象多进程访问静态变量的一些问题。例如，在某些 Linux 实现中，相同的内存与分叉进程共享，直到第一次内存写入。它调用写时复制。因此，如果我们在这样的系统上执行以下代码

#include <iostream>
#include <unistd.h>

using namespace std;

struct A
{
    A() {cout << __FUNCTION__ << '\n';}
    ~A() {cout << __FUNCTION__ << '\n';}
};

static void f()
{
    static A a;
}

int main()
{
    f();

    fork();    

    return 0;
}    

我们可以得到类似的输出

A
~A
~A

就是这样，析构函数的双重调用和构造函数的单次调用。这可能不应该是因为在其他系统上我们可以得到A ~A A ~A。所以我们可以想象一些静态变量的共同问题，但是共享库和块范围的静态变量的特殊问题是什么？

Answer 1

问题是会发生什么不兼容问题。

例如，在调用exit 之前并非所有线程都终止的多线程程序中，该库可能变得不可用。

也就是说，如果线程T0 调用了exit，那么Application 析构函数将在某个时候被调用（因为它在第一次调用theApp() 时注册了atexit）。

如果线程 T1 仍在运行，并且具有对 theApp.app 的引用，那么它现在将具有对被破坏对象的引用，并且可能会崩溃。

这被称为退出竞争，并且可能是高度不可重现的（如果T0 在T1 有机会崩溃之前达到sys_exit，您将观察到正常退出）。

更新：

析构函数的双重调用。这不应该是

您误会：这完全正确正常工作。这里没有对析构函数的双重调用：你有两个进程，每个进程都会析构自己的对象（应该如此）。