C++ 对象初始化

先写一个 Buffer

用三个零作为初始内容

上一篇类型推导文章讨论了变量的类型怎样确定。现在把类型明确写出来，继续看对象怎样获得初始状态。

假设我们需要一个保存整数的缓冲区。第一版只提供一种创建方式：传入元素数量，内容全部填零。

struct Buffer {
    std::vector<int> data;

    Buffer(int count) : data(count, 0) {}
};

Buffer a(3); // a.data 包含 0、0、0

data(count, 0) 用数量和初值构造内部的 vector。冒号后面是成员初始化列表，含义是“创建 Buffer 时，怎样先把它的成员建好”。

此时很容易理解 a(3)：把 3 交给构造函数。但如果换个写法呢？

换一种写法

四行都创建了三个零

仍然使用第一版 Buffer：

Buffer a(3);
Buffer b{3};
Buffer c = 3;
Buffer d = {3};

四行都合法，都调用 Buffer(int)，也都得到三个零。我们暂时只有一个构造入口，所以这些形式没有表现出区别。

但 c = 3 看起来很像赋值：难道编译器先创建一个空 Buffer，再把 3 赋给它？如果真是这样，我们至少需要一种不带参数创建 Buffer 的办法。第一版恰好没有这样的默认构造函数，这四行却仍然合法。

要解释这个现象，先把“创建对象”和“修改已有对象”分开。

等号出现在哪个阶段？

初始化与赋值

Buffer source(3);
Buffer copy = source; // 创建 copy，复制 source 的内容
copy = source;        // copy 已经存在，这次才是赋值

Buffer copy = source 使用编译器隐式声明的复制构造函数，它会复制成员 data。下一行则使用复制赋值运算符，给已有成员赋值。

再加上 const，区别就更直接了：

const Buffer fixed = source; // 可以初始化
// fixed = source;          // 不能给 const 对象赋值

回到 Buffer c = 3：它也在创建对象，调用的是 Buffer(int)。这个过程中没有“先默认构造，再赋值”。等号不能单独决定操作，要先看这是不是一条对象声明。

先给这些写法起名字

名称描述规则，不描述复制次数

刚才的四行分别属于下面几种初始化形式：

c 属于复制初始化，却调用 Buffer(int)；copy = source 的声明也是复制初始化，却调用复制构造函数。初始化形式决定使用哪套规则，具体调用什么，还要看类型和来源表达式。

到这里，四种形式的结果依然相同。接下来给 Buffer 增加一个限制，就能看到这些名称实际区分了什么。规范入口是 C++20 初始化总则。

一个意外合法的调用

构造函数也提供了转换路径

假设我们有一个处理缓冲区的函数：

void inspect(const Buffer& buffer);

inspect(3); // 第一版 Buffer 下合法

inspect 需要一个 Buffer，调用者却传了整数。编译器可以通过 Buffer(int) 创建临时缓冲区，再让参数引用绑定到它。这个临时对象会存活到包含调用的完整表达式结束，足以供本次调用使用。

问题在于，读到 inspect(3) 很难看出这里分配了三个元素。我们希望调用者把创建缓冲区的意图写出来。这个要求正是 explicit 的用途。

只增加一个 explicit

直接构造仍然可用

第二版只改构造函数的声明：

struct Buffer {
    std::vector<int> data;

    explicit Buffer(int count) : data(count, 0) {}
};

Buffer a(3);        // 可以
Buffer b{3};        // 可以
// Buffer c = 3;   // 编译错误
// Buffer d = {3}; // 编译错误

现在，直接初始化与复制初始化终于表现出区别。a、b 明确地用参数构造目标对象，可以使用 explicit 构造函数；c 不能再借它完成普通复制初始化。

d 的处理稍有不同：复制列表初始化先选构造函数，最后如果选中的是 explicit 构造函数，就拒绝整个初始化。它不会先排除 explicit 再另找一个。

回到 inspect(3)

让创建对象的意图出现在调用点

// inspect(3);       // 第二版下不再合法
inspect(Buffer{3});  // 明确创建 Buffer，再传给 inspect

Buffer{3} 使用刚才仍然合法的直接列表初始化。我们没有禁止用整数构造缓冲区，只是要求调用者明确请求这次构造。

所以，到目前为止，区别可以这样记：explicit 改变了哪些上下文允许使用这个构造函数，没有改变它创建三个零的行为。 规则见 转换构造函数。

不过，Buffer{3} 是否永远代表“三个零”？下一次接口扩展会改变这个答案。

数量之外，还想传元素

给 Buffer 增加列表构造函数

现在希望能写 Buffer{3, 7}，直接得到两个元素 3、7。第三版增加一个构造函数：

struct Buffer {
    std::vector<int> data;

    explicit Buffer(int count) : data(count, 0) {}
    Buffer(std::initializer_list<int> values) : data(values) {}
};

std::initializer_list<int> 可以访问花括号列表所对应的一组 const int 元素。这里把它交给 vector，让 data 保存这些元素。

数量构造函数没有改。但重新看第二版的调用代码，原来的 Buffer b{3} 已经不再表示三个零了。

旧代码的含义变了

圆括号选数量，花括号选元素

Buffer a(3);      // 三个零：0、0、0
Buffer b{3};      // 一个元素：3
Buffer c{3, 7};   // 两个元素：3、7
Buffer d = {3};  // 现在合法，一个元素：3

对第三版这样的非聚合类，非空列表初始化先考虑 initializer-list 构造函数。b 的列表可以作为一个 int 元素，因此选中新增的构造函数。

d 也选中它，而新增的构造函数没有 explicit，所以复制列表初始化现在合法了。第二版的 d 失败，是因为当时选中了另一个构造函数。

这两次变化来自同一件事：列表语法影响候选选择，选中的构造函数又决定后续是否合法、数据是什么。

把选择过程完整走一遍

只有第一轮无可行函数，才进入第二轮

以第三版的 Buffer b{3} 为例：

非空花括号列表，目标是这个非聚合类 Buffer
    ↓
先考虑 Buffer(std::initializer_list<int>)
    ↓
列表可以匹配，选中这个构造函数
    ↓
data 保存列表中的一个元素 3

如果第一轮没有可行的 initializer-list 构造函数，才把列表元素拆成参数，考虑普通构造函数。第二版没有列表构造函数，所以当时 Buffer b{3} 能走到数量构造函数。

这套规则也解释了常见的 vector<int>(3) 与 vector<int>{3} 的区别。这里限定了非聚合类和非空列表；空列表稍后会遇到。依据见 列表重载选择。

如果元素不是整数呢？

选中构造函数之后，还会检查转换

Buffer a(3.5);     // 可以：3.5 转成 int 3，创建三个零
// Buffer b{3.5}; // 编译错误：列表元素需要 double 转 int

两行都发生在第三版。a 走普通构造路径，允许这里从 double 到 int 的转换；explicit 没有禁止构造函数参数上的转换。

b 则先选中列表构造函数，但把 3.5 放进 int 元素需要窄化转换，列表初始化不允许它。编译器不会因为这一步失败，就退回数量构造函数。

前一张卡片说的“没有可行的列表构造函数”，与这里“选中了，但元素初始化不合法”，是两种不同情况。

换成 3.0 能不能通过？

窄化按转换类别判断

// Buffer a{3.0}; // 仍然是编译错误
Buffer b{static_cast<int>(3.5)}; // 一个元素：3

浮点到整数是列表初始化禁止的窄化类别，3.0 恰好没有小数部分也不能获得例外。

第二行则先显式转成 int，花括号收到的已经是整数。但第三版的列表选择规则没有消失：它仍然创建一个元素 3，不会变成三个零。

所以，解决窄化报错和选择想要的构造方式，是两个决定。若意图是数量，应该写 Buffer(3)；若意图是内容，才写 Buffer{3}。完整窄化规则见 列表初始化。

第三版已经支持了空列表

能写 Buffer，不代表能写 Buffer b

Buffer a{}; // 第三版：空列表交给列表构造函数，data 为空
// Buffer b; // 第三版：没有默认构造函数，编译错误

第三版没有默认构造函数，但它有 initializer-list 构造函数，因此可以用空列表构造。

这时又出现一个需求：希望直接声明 Buffer b; 也得到空缓冲区。我们给它增加默认构造函数，同时加入一个记录写入次数的成员。数据应该为空，计数应该为零——接下来要检查代码是否真的表达了这两个要求。

构造函数成功，不代表成员都初始化了

第四版遗漏了写入次数

struct Buffer {
    std::vector<int> data;
    int writes;

    Buffer() {}
    explicit Buffer(int count) : data(count, 0) {}
    Buffer(std::initializer_list<int> values) : data(values) {}
};

假定在函数内写 Buffer b;。它默认初始化 Buffer，调用 Buffer()。进入构造函数体前，data 已默认构造为空容器；writes 也是默认初始化，但对这个 int 不执行值的初始化。

因此，空函数体留下了一个不确定的计数值。在本文的 C++20 基线下，把它作为普通整数读取是未定义行为。

数量和列表构造函数也遗漏了 writes。问题已经不在“有没有选中构造函数”，而在它是否建立了完整的初始状态。

改成 Buffer b{} 就会清零吗？

花括号仍然要遵循类的构造规则

void example() {
    Buffer a;   // 第四版：data 为空，writes 没有确定初值
    Buffer b{}; // 第四版：同样不能读取 writes
}

现在类有默认构造函数，空列表会进入值初始化，使用 Buffer()，不再选择列表构造函数。

但值初始化不是对所有对象统一清零。这里 Buffer() {} 是用户提供的默认构造函数，不会得到值初始化中针对非用户提供默认构造函数的那一步预先零初始化。它自己没初始化 writes，花括号也没有替它补上。

第三版和第四版都能写 Buffer{}，走的路径却不同。初始化语法的含义必须结合当前类定义来判断。

把默认值写进类里

所有构造入口都需要有效的计数

第五版只改成员声明：

int writes = 0; // 替换第四版中的 int writes;

只要构造函数没有单独初始化 writes，就使用这个默认成员初值。于是第五版的结果可以一起检查：

数量和内容的差异保留了下来，而“写入次数从零开始”成为类自身的约定。调用者不用选择某种特殊写法才能得到有效计数。

为什么不在函数体里补赋值？

成员初始化发生在函数体之前

第五版的数量构造函数目前是：

explicit Buffer(int count) : data(count, 0) {}

如果替换成下面的写法，最终内容可以相同，但过程不同：

explicit Buffer(int count) {
    data = std::vector<int>(count, 0);
}

原版直接用数量和初值构造 data。替代版先把 data 默认构造为空容器，再在函数体里赋值。这正是第一节区分过的“创建”和“修改”，现在发生在成员上。

对这里的 vector，两条路径都可行；对于引用或不可默认构造的成员，就不能总等到函数体里再处理。成员初始化规则见 class.base.init。

把第五版放在一起

构造入口与成员默认值各自负责一部分

struct Buffer {
    std::vector<int> data;
    int writes = 0;

    Buffer() {}
    explicit Buffer(int count) : data(count, 0) {}
    Buffer(std::initializer_list<int> values) : data(values) {}
};

默认构造得到空内容，圆括号传整数表示数量，非空花括号表示元素列表。三个入口都使用 writes 的默认成员初值。

这些结果没有来自一句“总是用花括号”的建议。我们先弄清楚需要哪一种初始状态，再用相应规则表达它。这里保留空函数体，是为了与上一版比较；稍后的补充会解释 = default 为什么不只是换一种拼写。

再看最初的四行

同样的代码，随着类定义得到不同结果

这张表中的变化都已经有了原因：explicit 限制使用上下文，列表构造函数改变选择，成员初值保证状态。即使变量类型始终叫 Buffer，初始化行为也会随接口变化。

以后看到类似声明，先确认它在创建对象，再判断初始化形式、当前可用的构造路径，以及成员最后获得了什么状态。名称帮助定位规则，结果要沿这条过程解释。

从初始化走向类设计

构造函数需要保证什么？

回头看第四版的错误：它能通过编译，也成功调用了构造函数，但 writes 不能被安全读取。第五版补上默认成员初值，才使“每个新缓冲区的写入次数为零”成立。

这已经触及下一步的类设计：哪些条件必须在对象创建完成时成立，并在后续操作中维持？它们就是类的不变量。继续学习复制、移动、析构和 RAII 时，仍然可以问同一个问题：这次操作之后，对象处于什么状态，谁负责保证它有效？

初始化规则到这里便有了实际用途：它让我们解释一个对象如何成为可以使用的对象。