复杂对象的静态常量成员的初始化

我们知道，C++支持静态常量成员的方式来保存一些不可变的值。当我们的静态常量为一些简单值时（比如int，long），我们可以不需要管它们的初始化过程，因为编译器会帮我们妥善处理好。

但是这并不代表我们使用静态常量成员时不需要考虑一些初始化的问题。尤其当我们对一些较复杂静态常量成员对象初始化时，我们更应该关注一下它们的初始化过程。那么什么样的静态常量成员对象的初始化我们需要留意呢？就是那些存在或可能存在嵌套初始化的静态常量成员对象。事实上，嵌套初始化的静态常量成员对象，是非常容易出现初始化问题的。我们举一个小例子：
我们首先有两个对象A和B。其中B的构造需要使用A：

struct A { A(int _a) : mA(_a) {}; int mA; };
struct B { B(const A & _a) : mB(_a.mA) {}; int mB; };

之后我们构建一个C包含两个静态常量成员对象：
struct C
{
static const A sc_a;
static const B sc_b;
};

const A C::sc_a(1);
const B C::sc_b(sc_a);

看起来似乎没有问题，好像程序应该可以正常编译。恩，是的，确实没问题。结果也应该是对的。sc_a和sc_b中的mA的值应该都是1。但是，换一种写法，我们将两个定义换一换：
const B C::sc_b(sc_a);
const A C::sc_a(1);

很显然，依然可以运行但结果一定是不对的。得到的结果是sc_b中的mA的值为0（因为处于静态区，所有静态区的数据都会被预先置为0或为空）。我们以可以得到一个结论：对于嵌套的复杂静态常量成员对象而言，初始化化结果是否正确取决于它们的初始化顺序是否正确。

当然，上面的例子是非常简单的，我们也可以非常容易预测出编译器对于两个静态常量成员的初始化顺序。不过在实际使用中，问题往往没有这么简单，我们未必能够预料出它们的执行顺序甚至我们可能会忽略他们。

那么怎么样才能尽量避免这种事故的发生呢？

我们的预知性方法当然就是接触这种嵌套关系，两个静态常量成员之间，至少在初始化时是相互独立的。这样也可以降低一点代码的耦合性。不过事与愿违的是，有时候现实很残酷，我们必须需要这种嵌套关系该怎么办？

以上面的例子为例，这种情况下我们需要使用一个静态函数来包装我们的sc_a，以保证它一定可以在sc_b构造之前就被初始化出来：
struct C
{
static const B sc_b;
static const A & GetA()
{
static const A sc_a(1);
return sc_a;
}
};

const B C::sc_b(C::GetA());

通过静态函数GetA的包装，我们可以保证在构造sc_b时，无论如何都会先把sc_a构造出来再返回给sc_b进行构造。当然这样的话我们获取sc_a也需要通过静态函数获取。

4000