c++什么时候会生成默认构造函数
参考c++什么时候会生成默认构造函数 以及《深度探索C++对象模型》
在需要的时候，编译器会在用户没有定义的情况下，默认创建拷贝构造函数A::A()、复制构造函数、赋值运算符重载函数、析构函数A::~A()（非virtual）。
编译器一定为类生成构造函数了吗？只有一个空的类定义的话，我们可以肯定的说——没有。对编译器这样的做法，我们不必感到惊讶。试想一个空的类——没有数据成员，没有成员函数，即使生成了构造函数又能做什么呢？即便是生成了，也只是一个空构造函数而已。
代码如下：
A(){}
它什么也做不了，也什么都不必做。更“悲剧”，它的出现不仅没有任何积极意义，还会为编译器和程序运行增加完全不必要的函数调用负担。
若A为：
//例1
class A
{
public:
int var;
void fun(){}
};
//即便如此，结果还是和上边的一样，不生成构造函数！
//因为没有任何理由对var初始化，况且编译器也不知道用什么值给它初始化。
- 编译器生成默认构造函数的四个正当理由：
1、类A内数据成员是对象B，并且该对象B的类提供了一个默认构造函数。
若把int改为类B，如果B没有定义构造函数（和这里的A一个样子），那么编译器仍然没有理由生成构造函数——为B初始化什么呢？反之，B一旦定义了默认构造函数B::B()，即便它是空的，编译器就不得不为A创建默认构造函数了（这里不考虑编译器的深度优化）。因为A并不知道B的构造函数是什么样子。
2、类的基类提供了默认的构造函数。
现在，我们回到例子1，这里我们不修改var的类型，而是让A继承于另一个类C。代码如下：
class A:public C
我们都知道，在C++构造函数初始化语法中，构造函数会先初始化基类C，再初始化自身的数据成员或者对象。因此，这里的问题和对象成员var类似。如果基类C没有提供任何构造函数，那么编译器仍然不提供A的默认构造函数。如果C提供了默认构造函数，结果和前边类似。
结果不出所料，编译器为A生成了构造函数，并且调用了基类C定义的默认构造函数。同样，若C没有提供默认默认构造函数，而提供了其他构造函数，编译是无法通过的。
3、类内定义了虚函数
我们再次回到例子1，这次我们修改成员函数fun。代码如下：
virtual void fun(){}
我们把类A的成员函数fun修改为虚函数，再次看看是否产生了默认构造函数。
这次编译器“毫不客气”的为A生成了默认构造函数，虽然它没有调用任何其他的构造函数！这是什么原因呢？原来，C++为了实现多态机制，需要为类维护一个虚函数表（vftable），而每个该类的对象都保存一个指向该虚函数表的一个指针（一般保存在对象最开始的四个四节处，多态机制的实现这里暂不介绍）。编译器为A生成构造函数，其实不为别的，就为了保证它定义的对象都要正常初始化这个虚函数表的指针（vfptr）！
好了，因此我们得出编译器生成默认构造函数的第三个正当理由——类内定义了虚函数。这里可能还涉及一个更复杂点的情况：类内本身没有定义虚函数，但是继承了基类的虚函数。其实按照上述的原则，我们可以推理如下：基类既然定义了虚函数，那么基类本身就需要生成默认构造函数初始化它本身的虚函数表指针。而基类一旦产生了默认构造函数，派生类就需要产生默认构造函数调用它。同时，如果读者对多态机制了解清除的话，派生类在生成的默认构造函数内还会初始化一次这个虚函数表指针的。
4、类使用了虚继承。
最后，我们再次回到例子1，这次仍然让A继承于C，但是这次C是一个空类——什么都没有，也不会自动生成默认构造函数。但是A继承C的方式要变化一下。代码如下：
class A:public virtual C
A虚继承于C，这次又有什么不同呢？
这次编译器也生成了A的构造函数，并且初始化过程和虚函数时有点类似。细心观察下发现，这次构造函数也初始化了一张表——vbtable。了解虚继承机制的读者应该不会陌生，这张表叫虚基类表，它记录了类继承的所有的虚基类子对象在本类定义的对象内的偏移位置（至于虚继承机制的实现，我们以后详细探讨）。为了保证虚继承机制的正确工作，对象必须在初始化阶段维护一个指向该表的一个指针，称为虚表指针（vbptr）。编译器因为它提供A的默认构造函数的理由和虚函数时类似。
这样，我们得出编译器生成默认构造函数的第四个正当理由——类使用了虚继承。
到这里，我们把编译器为类生成默认构造函数的正当理由阐述完毕，相信大家应该对构造函数的生成时机有了一个大致的认识。这四种“正当理由”其实是编译器不得不为类生成默认构造函数的理由，《Inside The C++ Object Model》里称这种理由为nontrival的（候sir翻译的很别扭，所以怎么翻译随你啦）。除了这四种情况外，编译器称为trival的，也就是没有必要为类生成默认构造函数。这里讨论的构造函数生成准则的内容是写进C++Standard的，如此看来标准就是“贴合正常思维”的一套准则（简单YY一下），其实本就是这样，编译器不应该为了一致化做一些没有必要的工作。
通过对默认构造函数的讨论，相信大家对复制构造函数、赋值运算符重载函数、析构函数的生成时机应该可以自动扩展了。没错，它们遵循着一个最根本的原则：只有编译器不得不为这个类生成函数的时候（nontrival），编译器才会真正的生成它。
因此，正如标题所说，我们不要被C++语法中所描述的那些条条框框所“蒙骗”了。的确，相信这些生成规则不会对我们的编程带来多大的影响（不会产生错误），但是只有了解它们的背后操作，我们才知道编译器究竟为我们做了什么，我们才知道如何使用C++才能让它变得更有效率——比如消除不必要的构造和虚拟机制等（如果可以的话）。相信本文对C++自动生成的内容的描述让不少人认清对象构造函数产生的前因后果，希望本文对你有所帮助。
