查找 C++ 静态初始化顺序问题
我们在 静态初始化顺序方面遇到了一些问题惨败,我正在寻找方法来梳理大量代码以找到可能的事件.有关如何有效地做到这一点的任何建议?
We've run into some problems with the static initialization order fiasco, and I'm looking for ways to comb through a whole lot of code to find possible occurrences. Any suggestions on how to do this efficiently?
关于如何解决静态初始化顺序问题,我得到了一些很好的答案,但这不是我的问题.我想知道如何查找受此问题影响的对象.在这方面,埃文的回答似乎是迄今为止最好的;我不认为我们可以使用 valgrind,但我们可能有可以执行类似功能的内存分析工具.这只会在给定构建的初始化顺序错误的情况下发现问题,并且顺序可以随着每次构建而改变.也许有一个静态分析工具可以捕捉到这一点.我们的平台是在 AIX 上运行的 IBM XLC/C++ 编译器.
I'm getting some good answers on how to SOLVE the static initialization order problem, but that's not really my question. I'd like to know how to FIND objects that are subject to this problem. Evan's answer seems to be the best so far in this regard; I don't think we can use valgrind, but we may have memory analysis tools that could perform a similar function. That would catch problems only where the initialization order is wrong for a given build, and the order can change with each build. Perhaps there's a static analysis tool that would catch this. Our platform is IBM XLC/C++ compiler running on AIX.
推荐答案
初始化解决顺序:
首先,这只是一个临时解决方法,因为您有一些全局变量,您正试图摆脱它们但还没有时间(您最终会摆脱它们,不是吗?:-)
Solving order of initialization:
First off, this is just a temporary work-around because you have global variables that you are trying to get rid of but just have not had time yet (you are going to get rid of them eventually aren't you? :-)
class A
{
public:
// Get the global instance abc
static A& getInstance_abc() // return a reference
{
static A instance_abc;
return instance_abc;
}
};
这将保证它在首次使用时被初始化并在应用程序终止时被销毁.
This will guarantee that it is initialised on first use and destroyed when the application terminates.
C++11 确实保证这是线程安全的:
C++11 does guarantee that this is thread-safe:
§6.7 [stmt.dcl] p4
如果控制在变量初始化的同时进入声明,则并发执行等待初始化完成.
§6.7 [stmt.dcl] p4
If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
然而,C++03 并没有官方保证静态函数对象的构造是线程安全的.所以从技术上讲,getInstance_XXX()
方法必须用临界区来保护.从好的方面来说,gcc 有一个显式补丁作为编译器的一部分,它保证每个静态函数对象即使在存在线程的情况下也只会被初始化一次.
However, C++03 does not officially guarantee that the construction of static function objects is thread safe. So technically the getInstance_XXX()
method must be guarded with a critical section. On the bright side, gcc has an explicit patch as part of the compiler that guarantees that each static function object will only be initialized once even in the presence of threads.
请注意:不要使用双重检查锁定模式a> 尽量避免锁定的成本.这在 C++03 中不起作用.
Please note: Do not use the double checked locking pattern to try and avoid the cost of the locking. This will not work in C++03.
在创建时,没有问题,因为我们保证它是在使用之前创建的.
On creation, there are no problems because we guarantee that it is created before it can be used.
在对象被销毁后访问对象存在潜在问题.仅当您从另一个全局变量的析构函数访问对象时才会发生这种情况(全局,我指的是任何非局部静态变量).
There is a potential problem of accessing the object after it has been destroyed. This only happens if you access the object from the destructor of another global variable (by global, I am referring to any non-local static variable).
解决方案是确保您强制执行销毁顺序.
请记住,破坏顺序与构造顺序完全相反.所以如果你在你的析构函数中访问对象,你必须保证对象没有被销毁.为此,您必须确保在构造调用对象之前完全构造该对象.
The solution is to make sure that you force the order of destruction.
Remember the order of destruction is the exact inverse of the order of construction. So if you access the object in your destructor, you must guarantee that the object has not been destroyed. To do this, you must just guarantee that the object is fully constructed before the calling object is constructed.
class B
{
public:
static B& getInstance_Bglob;
{
static B instance_Bglob;
return instance_Bglob;;
}
~B()
{
A::getInstance_abc().doSomthing();
// The object abc is accessed from the destructor.
// Potential problem.
// You must guarantee that abc is destroyed after this object.
// To guarantee this you must make sure it is constructed first.
// To do this just access the object from the constructor.
}
B()
{
A::getInstance_abc();
// abc is now fully constructed.
// This means it was constructed before this object.
// This means it will be destroyed after this object.
// This means it is safe to use from the destructor.
}
};
相关文章