动态库是否打破了C++标准？

Question

C++标准3.6.3规定

静态持续时间的初始化对象的析构函数被调用为从main返回并且由于调用exit而返回的结果

在Windows上你有FreeLibrary和linux你有dlclose来卸载一个动态链接的库.你可以在从main返回之前调用这些函数.

卸载共享库的一个副作用是运行库中定义的静态对象的所有析构函数.

这是否意味着它违反了C++标准,因为这些析构函数已经过早运行了？

Answer 1

这是一个毫无意义的问题.C++标准没有说明dlclose应该做什么或应该做什么.

如果标准包含规范dlclose,那么肯定会指出这dlclose是3.6.3的例外.因此,3.6.3不会被违反,因为它将是一个记录在案的例外.但我们无法知道,因为它没有涵盖它.

dlclose对C++标准中的保证有什么影响,这超出了该标准的范围.没有dlclose什么可以违反C++标准,因为标准没有说明它.

(如果没有程序执行任何特定的调用它就会发生这种情况,那么你就会有一个合理的论据,即标准被违反了.)

Answer 2

Parapura,请记住,C++标准是一种语言定义,对编译器如何将源代码转换为目标代码施加约束可能会有所帮助.

该标准不对操作系统,硬件或其他任何内容施加约束.

如果用户关闭他的机器,是否违反了C++标准？当然不是.标准是否需要说"除非用户关闭设备"作为每个规则的"例外"？那太傻了.

同样,如果操作系统杀死某个进程或强制释放某些系统资源,或者甚至允许第三方程序破坏您的数据结构 - 这不违反C++标准.它可能是操作系统中的一个错误,但C++语言定义仍然完好无损.

该标准仅对编译器具有约束力,并强制生成的可执行代码具有某些属性.然而,它并没有绑定运行时行为,这就是我们在异常处理上花费这么多时间的原因.

Answer 3

我认为这是一个开放式的问题.

我会说是这样的:标准只定义了一个程序是什么.一个程序(一个"托管"的程序,我应该添加)是一个编译和链接的翻译单元的集合,具有唯一的main入口点.

共享库没有这样的东西,所以它甚至不构成标准意义上的"程序".它只是一堆链接的可执行代码,没有任何"流".如果使用加载时链接,则库将成为程序的一部分,并且所有内容都符合预期.但是如果使用运行时链接,情况就不同了.

因此,您可能希望像这样查看:运行时链接共享对象中的全局变量本质上是动态对象,它由动态加载器构造,并在卸载库时被销毁.这些对象被声明为全局对象的事实并没有改变这一点,因为那时对象不是"程序"的一部分.

Answer 4

如果您付出巨大努力，它们只会过早运行 - 默认行为是符合标准的。