C ++ 11允许非静态和非const成员的类内初始化。发生了什么变化？

Question

在C ++ 11之前，我们只能对整数或枚举类型的静态const成员执行类内初始化。Stroustrup在他的C ++ FAQ中对此进行了讨论，并给出了以下示例：

class Y {

  const int c3 = 7;           // error: not static

  static int c4 = 7;          // error: not const

  static const float c5 = 7;  // error: not integral

};

并进行以下推理：

那么为什么存在这些不便的限制呢？通常在头文件中声明类，并且通常将头文件包含在许多翻译单元中。但是，为避免复杂的链接器规则，C ++要求每个对象都有唯一的定义。如果C ++允许对需要作为对象存储在内存中的实体进行类内定义，则该规则将被打破。

但是，C ++ 11放宽了这些限制，允许对非静态成员进行类内初始化（第12.6.2 / 8节）：

在非委托构造函数中，如果给定的非静态数据成员或基类未由mem-initializer-id指定（包括没有mem-initializer-list的情况，因为构造函数没有ctor-initializer）并且该实体不是抽象类（10.4）的虚拟基类，则

如果实体是具有brace-or-equal-initializer的非静态数据成员，则按照8.5中的指定进行初始化；

否则，如果实体是变量成员（9.5），则不执行初始化。

否则，该实体为默认初始化（8.5）。

如果非常量成员用说明constexpr符标记，则9.4.2节还允许非常量成员的类内初始化。

那么，我们在C ++ 03中受到限制的原因发生了什么？我们是否只是接受“复杂的链接器规则”，还是进行了其他更改以使其更容易实现？

Answer 1

简短的答案是，它们使链接程序保持相同，但代价是使编译器比以前更加复杂。即，除了导致链接器要定义多个定义之外，它仍然仅生成一个定义，而编译器必须对其进行分类。这也导致程序员要整理出一些更复杂的规则，但是它非常简单，所以没什么大不了的。当您为单个成员指定了两个不同的初始化程序时，就会出现额外的规则：class X {&nbsp;&nbsp; &nbsp; int a = 1234;public:&nbsp; &nbsp; X() = default;&nbsp; &nbsp; X(int z) : a(z) {}};现在，这时的额外规则处理a使用非默认构造函数时用于初始化的值。答案很简单：如果使用未指定任何其他值的构造函数，1234则将使用初始化a-但是，如果使用指定其他值的构造函数，1234则基本上忽略。例如：#include <iostream>class X {&nbsp;&nbsp; &nbsp; int a = 1234;public:&nbsp; &nbsp; X() = default;&nbsp; &nbsp; X(int z) : a(z) {}&nbsp; &nbsp; friend std::ostream &operator<<(std::ostream &os, X const &x) {&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; return os << x.a;&nbsp; &nbsp; }};int main() {&nbsp;&nbsp; &nbsp; X x;&nbsp; &nbsp; X y{5678};&nbsp; &nbsp; std::cout << x << "\n" << y;&nbsp; &nbsp; return 0;}结果：12345678

Answer 2

我猜想推理可能是在模板完成之前编写的。对于C ++ 11支持模板的静态成员而言，对于静态成员的类内初始化器来说，所有必需的“复杂链接器规则”已经存在。考虑struct A { static int s = ::ComputeSomething(); }; // NOTE: This isn't even allowed,&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// thanks @Kapil for pointing that out// vs.template <class T>struct B { static int s; }template <class T>int B<T>::s = ::ComputeSomething();// ortemplate <class T>void Foo(){&nbsp; &nbsp; static int s = ::ComputeSomething();&nbsp; &nbsp; s++;&nbsp; &nbsp; std::cout << s << "\n";}在所有三种情况下，编译器的问题都是相同的：它应在哪个转换单元中发出的定义s以及对其进行初始化所需的代码？一种简单的解决方案是将其发送到任何地方，然后让链接程序对其进行整理。这就是链接器已经支持诸如之类的原因的原因__declspec(selectany)。没有它，就不可能实现C ++ 03。这就是为什么没有必要扩展链接器的原因。坦率地说：我认为旧标准中的推理完全是错误的。更新正如Kapil指出的那样，当前标准（C ++ 14）甚至不允许我的第一个示例。无论如何，我还是保留了它，因为IMO是实现过程中最困难的情况（编译器，链接器）。我的观点是：即使是这种情况，也没有比例如使用模板时所允许的情况难。

Answer 3

从理论上讲，So why do these inconvenient restrictions exist?...原因是有效的，但可以轻松地绕开它，而这正是C ++ 11所做的。当你有一个文件，它只是包括文件和忽略任何初始化。仅在实例化类时才初始化成员。换句话说，初始化仍然与构造函数联系在一起，只是表示法有所不同并且更加方便。如果未调用构造函数，则不会初始化值。如果调用了构造函数，则使用类内初始化（如果存在）初始化值，否则构造函数可以使用自己的初始化覆盖它们。初始化的路径本质上是相同的，即通过构造函数。从Stroustrup自己在C ++ 11上的常见问题中可以明显看出这一点。