Item 4：确定对象使用前已经初始化

从“有存储不等于有有效对象”开始

与

不是同一阶段。构造函数体执行前，基类与所有成员已经初始化；在函数体中写 member = value 是再次赋值。

应在初始化结束时成立，而不是等待调用方再执行 setup。

内置类型也要显式初始化

原书指出 C++ 不同语境下内置类型初始化规则复杂，最可靠习惯是对象使用前明确给值。

int retryCount{};
double timeoutSeconds{2.5};
Widget* selected{};
std::array<int, 4> histogram{};

int count; 在自动存储期可能保持不确定值；读取它会导致未定义行为或错误分支。成员可给

default member initializer，

降低多个构造函数遗漏风险。

class ConnectionOptions {
public:
    explicit ConnectionOptions(std::string endpoint)
        : endpoint_{std::move(endpoint)} {}
private:
    std::string endpoint_;
    int retries_{3};
    bool encrypted_{true};
};

仍需审查每个字段是否有合理默认；{} 不是业务正确性的万能值。

成员初始化列表直接构造

错误方式先默认构造 string，再赋值：

class AddressEntry {
public:
    AddressEntry(const std::string& name, const std::string& address)
    {
        name_ = name;
        address_ = address;
    }
private:
    std::string name_;
    std::string address_;
};

正确方式一次复制构造：

AddressEntry::AddressEntry(const std::string& name,
                           const std::string& address)
    : name_{name}, address_{address}
{}

对 class 成员可能多做一次构造和赋值；对 const/reference 成员甚至无法在函数体赋值，必须列表初始化。

和 const member 都迫使接口尽早确定依赖，通常是好事。

初始化顺序由声明决定

initializer list 书写顺序不会改变真实顺序。

class Session {
public:
    Session(std::string endpoint)
        : connection_{endpoint_}, endpoint_{std::move(endpoint)} {}
private:
    Connection connection_; // 先初始化，却依赖尚未初始化的 endpoint_
    std::string endpoint_;
};

这里即使 list 先写 endpoint，connection* 仍按声明顺序先构造并读取未开始生命周期的 endpoint*。

应让被依赖成员先声明，并让 list 顺序与声明一致，编译器警告更清楚。

基类先于派生成员

虚基类由最派生对象负责并最先初始化，然后直接基类，再到成员，最后构造函数体。析构顺序完全反向。

virtual bases
  -> direct bases
  -> data members in declaration order
  -> constructor body

初始化列表最好按此顺序书写，减少审查时的认知偏差。

多构造函数共享默认值

现代 C++ 可让一个主构造函数维护不变量，其余构造函数委托：

class Timer {
public:
    Timer(std::chrono::milliseconds period, bool repeating)
        : period_{validate(period)}, repeating_{repeating} {}
 
    explicit Timer(std::chrono::milliseconds period)
        : Timer{period, false} {}
private:
    std::chrono::milliseconds period_;
    bool repeating_;
};

避免多个构造函数复制验证逻辑。委托完成后，委托构造体可做附加工作，但不应重新建立另一套不变量。

non-local static 的跨单元顺序

同一翻译单元内可按定义顺序推断动态初始化；不同翻译单元之间，如果一个 non-local static 构造依赖另一个，次序通常不可靠。

// filesystem.cpp
FileSystem globalFileSystem;
 
// directory.cpp
Directory tempDirectory(globalFileSystem.root()); // 跨翻译单元依赖

链接顺序或构建变化即可触发“有时工作”。

construct-on-first-use

FileSystem& fileSystem()
{
    static FileSystem instance;
    return instance;
}
 
Directory& tempDirectory()
{
    static Directory instance{fileSystem().root()};
    return instance;
}

调用 tempDirectory() 时会先调用 fileSystem()，依赖顺序变得显式。C++11 起函数局部 static 的首次初始化具有线程安全保证。

如果两个 accessor 构成循环依赖，模式不能自动解决；需要重构依赖图或显式启动阶段。

退出阶段仍需审计

局部 static 在成功构造后会登记析构。若 A 先构造、B 后构造，通常 B 先析构；但跨 accessor 的退出调用仍可能形成悬空依赖。

复杂系统常由 Application 对象拥有各服务，比大量全局 static 更容易测试。对进程寿命单例，有时刻意不析构可避免退出次序，但必须明确资源与工具影响，不能随意泄漏。

初始化审计与测试

Make sure that objects are initialized before they are used（确定对象使用前已经初始化）应作为所有存储期的统一门禁：自动对象有明确领域初值，成员在构造体前直接完成，non-local static objects 不依赖跨单元偶然顺序。这里的 initialization order（初始化顺序）同时包含虚基类、直接基类、成员声明和静态动态初始化，不能只检查 initializer list 的视觉排列。

先预测：把 initializer list 顺序交换是否改变真实顺序？把两个 global 放在不同 .cpp 后能否依赖链接顺序？写下语言保证，再运行测试。

• 开启 -Wreorder/对应编译器警告并视为错误。
• 用计数类型断言成员只复制构造一次，没有 default-then-assign。
• MemorySanitizer/UBSan 捕获未初始化读取与生命周期错误。
• 两个翻译单元分别定义 static，反转链接顺序重复测试。
• 多线程同时首次调用 accessor，构造计数恰好为一。
• 测试退出路径，析构日志不访问已销毁服务。

小结

• initialization 开始生命周期并建立不变量，assignment 只替换已存在对象的值
• 内置类型也要明确初值，但语言层零值不等于领域有效值
• member initialization list 一次构造成员，避免 default-then-assign
• 基类和成员真实顺序由继承列表与声明顺序决定，不由初始化列表书写顺序决定
• 跨翻译单元 non-local static 顺序不可依赖，优先 function-local static accessor
• 首次构造线程安全不等于退出依赖安全，复杂服务应考虑显式 Application 生命周期