【复读EffectiveC++04】条款04：确定对象被使用前已被初始化

条款04：确定对象被使用前已被初始化

   这个条款，初看的时候，没有太大感受，但当我参与进行多人合作的项目时候，就为了一个声明后不初始化，引起重现困难的bug，付出了不少的时间，最后，我直接把写这个bug的兄弟揍了一边，我做的对么？
   回归正题，本书在这个条款上主要包括三个部分：
   a、为什么要初始化；
   b、类中变量的初始化；
   c、静态变量的初始化；

一、为什么要初始化

   在c语言中对于变量，就存在要求，即“先定义，后使用”。

int x;
x = 1;

int x = 1;

  也正是因为这个要求，c语言的变量如果未初始化，其变量值是随机的，特别是对指针而言，很容易导致程序崩溃。
例如，创建一个数组，然后输出：

#include<stdio.h>
int main() {
	int array[10];
	for (int i = 0; i < 10; i++) {
		printf("%d\n", array[i]);
	}
	return 0;
}

这种情况，如果你学过计算机专业课，就应该能分析出来原因，数组是一段连续的空间，是被分配的，但在分配之前，这个空间是可能有数据残留的，毕竟空间是反复利用的，分配不代表就要把空间重新清理的。

二、类中变量的初始化

   我们扩展到C++范围，类就要加入考虑了。
   我见过很多C++中各种充满“个性”的初始化。

1、假初始化情况

class CMyObj
{
public:
    void Init()
    {
        m_iV = 1;
    }

public:
    int m_iV;
};

int main() {
    CMyObj cMyObj;
	cMyObj.Init();

	return 0;
}

   情况一：自己定义Init函数，在Init函数里面赋值，就被当成 “ 初始化 ” 了。

class CMyObj
{
public:
    CMyObj()
    {
        m_iV = 1;
    }

public:
    int m_iV;
};

int main() {
    CMyObj cMyObj;

	return 0;
}

  情况二：自己在类的构造函数内进行成员变量赋值的，就被当成“ 初始化 ” 了，这种情况在很多公司应该是很普遍的吧 。

  以上两种情况，其实都不是在标准初始化，而是在赋值，只是模拟初始化，尽量做到，类对象生成后更早的赋值而已，更不要说前者容易忘记init，后者存在着性能上的消耗，这种消耗积累起来，也是很要命的。

2、初始化列表

  C++ 有着十分固定的"成员初始化顺序"。

初始化顺序： 成员变量声明时初始化-> 初始化列表初始化-> 构造函数初始化。

也因此，如果想要对成员进行初始化，应该是在构造函数的成员初始化列表对成员数据进行初始化。

class CMyObj
{
public:
    CMyObj() 
    : m_iV1(1), m_iV2(2)
    {

    }

public:
    int m_iV1;
    int m_iV2;
};

int main() {
    CMyObj cMyObj;

	return 0;
}

   情况二与初始化列表初始化相比，就存在着性能上的消耗，即初始化列表初始化先发生，给予成员变量初值，然后构造函数初始化阶段进行再一次赋值，效率更低，而且还满足初始化的概念，即初始化只能进行一次，而构造函数体内可以多次赋值。

三、静态对象的初始化

  const所谓静态对象，其生命周期从定义开始，直到程序结束为止。程序结束时它们会被自动销毁。也就是它们的析构函数会在 main() 结束时被自动调用。
  静态成员分类：
  a、非局部的静态对象：全局静态对象、定义与namespace作用域内的对象、class的静态成员。
  b、局部的静态对象：函数内部的局部静态变量。
原文主要探讨在不同编译单元之间定义“非局部的静态对象”的初始化顺序问题，如下例：

编译单元：是指产出单一目标文件的源码，通常是一个源文件加上一个头文件的组合。

  现在有一个FileSystem类，它类似于一个文件系统，供网络上的用户使用，其定义在FileSystem.h文件中。定义如下：

//FileSystem.h
class FileSystem
{
public:
	...
    std::size_t numDisks()const;
    ...
}; 
extern FileSystem tfs;

  现在客户端程序在Directory.h中建立Directory类用来处理文件系统内的目录

//Directory.h
 
#include "FileSystem.h"
class Directory
{
public:
    Directory( params );
    ...
};
 
Directory::Directory()
{
	...
    std::size_t disks = tfs.numDisks(); //使用tfs对象
    ...
}

//进一步加设，客户在主程序中创建一个Directory对象，用来放置临时文件
Directory tempDir(params); //为临时文件而做出的目录

  现在问题来了：如果要使用tempDir，必须确保tfs对象在这之前已经被初始化了，否则tempDir就会用到未初始化的tfs。但是tfs对象与tempDir对象是出于不同编译单元之间的对象，那怎样才能保证tfs在tempDir使用之前已经被初始化了呢？答案是无法确定。

  幸运的是，有一个小小的设计就可以确保上面的这个问题。经需要用到的非局部静态对象封装到一个函数内，对象在函数内部被声明为static，然后函数返回一个指向这个对象的引用。用户之后调用这些函数，而不是直接调用这些对象。此处非局部静态对象被局部对象替换了。这在设计模式中，是Singleton模式的一种常见手法

  这种手法保证：函数内的局部静态对象会在“该函数被调用期间，第一次遇到该对象的定义时”被初始化 。

//FileSystem.h
class FileSystem
{
public:
    std::size_t numDisks()const;
};
 
FileSystem& tfs()
{
    static FileSystem tfs;
    return fs;
}

//Directory.h
 
#include "FileSystem.h"
class Directory
{
public:
    Directory();
};
 
Directory::Directory()
{
    std::size_t disks = tfs.numDisks(); //使用tfs对象
}
 
//这个函数用来替换tempDir对象，它在Directory内部可能是static
Directory& tempDir()
{
    static Directory td;
    return td;
}

四、总结

1、为内置型对象进行手工初始化，因为C++不保证初始化它们。
2、构造函数最好使用成员初始化列表，而不要再构造函数体内部做赋值操作。初始列列出的成员变量，其排列次序应该和它们在 class 中的声明次序相同。
3、为免除“跨编译单元之初始化次序”问题，请以局部静态对象替换非局部静态对象。