item1：理解模板类型推导

什么是函数模板？

问题场景：假设我们要写一个函数，用来比较两个数并返回较大的那个。

// 比较两个 int
int max_int(int a, int b) {
    return (a > b) ? a : b;
}

// 比较两个 double
double max_double(double a, double b) {
    return (a > b) ? a : b;
}

// 比较两个 char
char max_char(char a, char b) {
    return (a > b) ? a : b;
}

int main() {
    std::cout << max_int(10, 20) << std::endl;      // 输出 20
    std::cout << max_double(3.14, 2.71) << std::endl; // 输出 3.14
    std::cout << max_char('A', 'Z') << std::endl;     // 输出 Z
}

这三个函数的逻辑完全一样，唯一的区别就是参数和返回值的类型不同。这导致了大量的代码冗余。如果我们还想比较 float、long 等类型，就需要写更多重复的函数。

解决方案：使用函数模板

#include <iostream>

// 这就是函数模板
template <typename T>	// 可以用class关键字代替typename
T generic_max(T a, T b) {
    return (a > b) ? a : b;
}

int main() {
    // 编译器看到这里传入了两个 int
    // 于是自动用 int 替换 T，生成一个 int generic_max(int, int) 函数
    std::cout << generic_max(10, 20) << std::endl;

    // 编译器看到这里传入了两个 double
    // 于是自动用 double 替换 T，生成一个 double generic_max(double, double) 函数
    std::cout << generic_max(3.14, 2.71) << std::endl;

    // 编译器看到这里传入了两个 char
    // 于是自动用 char 替换 T，生成一个 char generic_max(char, char) 函数
    std::cout << generic_max('A', 'Z') << std::endl;
    
    // 我们甚至可以用它来比较 std::string
    std::string s1 = "hello";
    std::string s2 = "world";
    std::cout << generic_max(s1, s2) << std::endl; // 输出 world
}

模板类型的推导

ParamType既不是指针也不是引用

当ParamType既不是指针也不是引用时，我们通过传值（pass-by-value）的方式处理

template<typename T>
void f(T param);                //以传值的方式处理param

当一个函数模板的参数是按值传递时（例如 T x），编译器在推导 T 的类型时会遵循以下规则：

参数的 const、volatile 和引用 & 属性都会被忽略（或称“剥离”）。

为什么呢？因为函数无论如何都会得到一个全新的、独立的副本。原始变量是不是 const，或者是不是一个引用，对于这个新创建的副本来说都无所谓。副本本身就是一个普通的、可修改的局部变量。param是一个完全独立于cx和rx的对象——是cx或rx的一个拷贝

例子：

template<typename T>
T increse(T x){
    return ++x;
}

int main() {
    int x = 1;
    const int cx = x;
    const int& rx = x;

    std::cout << "increse(x):" << increse(x) << std::endl;
    std::cout << "x:" << x << std::endl;
    std::cout << "increse(cx): "<< increse(cx) << std::endl;
    std::cout << "cx:" << cx << std::endl;
    std::cout << "increse(rx):" << increse(rx) << std::endl;
    std::cout << "rx:" << rx << std::endl;
}

打印结果：

increse(x):2
x:1
increse(cx): 2
cx:1
increse(rx):2
rx:1

ParamType是指针或者非通用引用

非通用引用，就是T&

template<typename T>
T increse(T& x){
    return ++x;
}

当我们把参数从值传递 (T x) 改为引用传递 (T& x) 时，类型推导的规则也发生了根本性的变化：

对于引用参数，const 属性会被保留在类型推导中。

为什么呢？这是为了保证 C++ 的“const 正确性” (const-correctness)。语言不允许你创建一个非 const 的引用去指向一个 const 的变量，因为那样会给你一个修改常量的“后门”。所以，如果传入的实参是 const 的，T 就必须被推导为 const 类型，以形成一个合法的 const 引用。

逐行分析：

调用 1: increse(x)

• 参数: x 的类型是 int。
• 类型推导: 编译器需要将 T& 与 int 匹配。为了让 T& 成为 int&，T 被直接推导为 int。
• 模板实例化: 编译器生成 T = int 的版本：

int increse(int& x) { // x 是 main 函数中 x 的引用
    return ++x;       // main 函数中的 x 被修改为 2，然后返回 2
}

• 行为:
  • main 函数中的 x 的值被永久地从 1 修改为 2。
  • 输出 2。
• 结果: 编译成功，并有副作用。

调用 2: increse(cx)

• 参数: cx 的类型是 const int。
• 类型推导: 编译器需要将T&与const int匹配。
  • 根据新规则，const 属性必须被保留。
  • 因此，T 被推导为 const int。这样 T& 就变成了 const int&，这是一个合法的引用，可以绑定到 const int 类型的 cx 上。
• 模板实例化: 编译器尝试生成 T = const int 的版本

// 这是编译器尝试生成的函数
const int increse(const int& x) {
    return ++x; // <-- 错误在这里！
}

• 问题: 在这个生成的函数体内，参数 x 的类型是 const int&。我们不能对一个常量（或常量引用）使用 ++ 自增操作符，因为这个操作符会试图修改它的值。
• 结果: 编译失败！ 编译器会报错，错误信息通常类似于：“对只读参数 'x' 进行自增操作” 或 “increment of read-only parameter 'x'”。

调用 3: increse(rx)

• 参数: rx 的类型是 const int&。
• 类型推导: 和上一个例子完全一样。rx 是一个对 const int 的引用，所以传递给函数的实参本质上就是那个 const 的值。为了匹配 T&，T 必须被推导为 const int。
• 模板实例化: 编译器同样尝试生成 const int 版本的函数，也同样会在 return ++x; 这一行遇到错误。
• 结果: 编译失败！ 原因和调用 increse(cx) 完全相同

在第三个例子中，注意即使rx的类型是一个引用，T也会被推导为一个非引用 ，这是因为rx的引用性（reference-ness）在类型推导中会被忽略。

ParamType是通用引用(转发引用)

当 T&& 出现在一个需要进行模板类型推导的上下文时，它就变成了“通用引用”。

• 定义：它是一种特殊的引用，既可以绑定到左值，也可以绑定到右值。它会根据传入参数的值类别（左值或右值）来改变自己的行为。
• 语法：T&&，其中 T 是一个正在被推导的函数模板参数。
• 主要用途：实现完美转发 (Perfect Forwarding)，即在函数调用链中保持参数原始的值类别（左值还是右值）。

例子：

template<typename T>
void forwarder(T&& arg) { // 这里的 arg 是一个通用引用（转发引用）
    // ... 在这里我们可以用 std::forward<T>(arg) 来完美转发 ...
    std::cout << "参数被接收..." << std::endl;
}

int main() {
    int x = 10;
    const int cx = 20;

    forwarder(x);       // 正确！传入一个左值 int
    forwarder(cx);      // 正确！传入一个 const 左值 int
    forwarder(42);      // 正确！传入一个右值 int
    forwarder(std::move(x)); // 正确！传入一个右值 int
}

1. 当传入一个左值时 (例如 int x)：

   模板参数 T 会被推导为 int& (一个左值引用类型)

   函数参数的类型就变成了 T&& -> int& &&

   根据引用折叠规则，& + && 折叠成 &

   所以，最终的函数参数类型是 int&，一个普通的左值引用

2. 当传入一个右值时 (例如 42)：

   模板参数 T 会被推导为 int (一个非引用类型)

   函数参数的类型就变成了 T&& -> int&&

   这本身就是一个右值引用，无需折叠

   最终的函数参数类型是 int&&，一个右值引用

通用转发有什么用？

看下面这个例子：

#include <vector>
#include <string>
#include <iostream>

struct Person {
    std::string name;
    int age;

    Person(const std::string& n, int a) : name(n), age(a) {
        std::cout << "构造函数 (const std::string&, int) 被调用" << std::endl;
    }
    Person(const Person& other) : name(other.name), age(other.age) {
        std::cout << "拷贝构造函数被调用" << std::endl;
    }
    Person(Person&& other) noexcept : name(std::move(other.name)), age(other.age) {
        std::cout << "移动构造函数被调用" << std::endl;
    }
};

int main() {
    std::vector<Person> people;
    
    // 关键！提前预留足够的空间，避免重分配
    people.reserve(2); 

    std::cout << "--- 使用 push_back ---" << std::endl;
    // 过程：
    // 1. 在 main 函数栈上创建一个临时的 Person 对象 ("Alice", 25)。
    // 2. push_back 接收这个临时对象。
    // 3. 在 vector 内部的内存空间，调用移动构造函数，将临时对象的内容移动过去。
    people.push_back(Person("Alice", 25));
    // 输出:
    // 构造函数 (const std::string&, int) 被调用
    // 移动构造函数被调用    
    std::cout << "\n--- 使用 emplace_back ---" << std::endl;
    // 过程：
    // 1. emplace_back 接收构造函数所需的参数 ("Bob", 30)。
    // 2. 它在vector 内部预留好的内存空间里，直接调用 Person 的构造函数，原地构造对象。 
    people.emplace_back("Bob", 30);
    // 输出:
    // 构造函数 (const std::string&, int) 被调用    
}

运行结果：

--- 使用 push_back ---
构造函数 (const std::string&, int) 被调用
移动构造函数被调用

--- 使用 emplace_back ---
构造函数 (const std::string&, int) 被调用

emplace_back 是如何做到的？

它的函数签名大致如下：

template<typename... Args>
void emplace_back(Args&&... args) {
    // ... 在 vector 内部申请内存 ...
    // 使用完美转发，将接收到的参数原封不动地传递给 Person 的构造函数
    new (memory_location) Person(std::forward<Args>(args)...);
}

• Args&&... args 就是一个通用引用的参数包。
• 如果调用 emplace_back("Bob", 30)，"Bob" 是右值，30 也是右值，std::forward 会将它们作为右值转发给 Person 的构造函数。
• 如果调用 std::string name = "Charlie"; emplace_back(name, 40);，name 是左值，std::forward 会保证它作为左值被转发，从而调用 Person(const std::string&, int) 构造函数。

数组实参

template<typename T>
void f(T arr){
    std::cout << "size of arr is:" << sizeof(arr) << std::endl;
}

int main() {
    int arr[3] = {1, 2, 3};
    f(arr);
    
}

//打印结果：8

在以上例子中，T 被推导为 int\* (一个指向 int 的指针)。

在 C++ 中，当一个数组名在大多数表达式中使用时（有少数例外），它会自动 “退化” 或 “转换” 为一个指向其首元素的指针。

f(arr) 这个函数调用就是一个典型的会发生数组退化的表达式。当你把数组 arr (其类型是 int[3]) 作为参数传递给函数 f 时，它实际上被转换成了一个指向 arr[0] 的指针，这个指针的类型是 int*。

模板函数 f 的参数是 T，这是一个按值传递 (pass-by-value) 的参数。类型推导机制会查看你传递给函数的实际值的类型。由于 arr 已经退化成了 int* 类型的指针值，所以模板系统将 T 推导为 int*。

怎么防止数组类型在模板推导时退化成指针呢？使用引用！

简单来说，引用可以防止数组退化，是因为引用直接绑定到对象本身，而不需要获取该对象的“值”。数组退化恰恰发生在“获取数组的值”这个过程中。

f的形参（该数组的引用）的类型则为int (&)[3]

让我们用一个形象的比喻来解释，然后深入到编译器的行为。

假设你有一个实体文件夹，里面有三份文件，文件夹上贴着标签“项目 A” (int arr[3])。

• 场景一：按值传递（会退化）
  • 我让你把“项目 A”文件夹里的内容给我。
  • 你不会把整个文件夹给我。按照惯例，你会告诉我：“内容在一楼第一个抽屉里”。你给我的是一个地址/指针 (int*)。
  • 我拿到了这个地址，但我不知道这个“项目”到底有多大（是3份文件还是10份？），我只知道从哪里开始找。
  • 这就是数组退化：为了“传递”这个数组，你把它简化成了一个指向其开头的指针。
• 场景二：按引用传递（不退化）
  • 我说：“让我直接使用一下你的‘项目 A’文件夹”。
  • 你没有给我地址，也没有给我复印件。你只是授权我直接操作你桌上那个原封不动的文件夹。
  • 我操作的就是那个原始的、完整的、带有“3份文件”这个全部信息的文件夹 (int[3])。我给它起了个别名来用，但它本质没变。
  • 这就是引用：它创建了一个别名，直接绑定到原始对象上，对象的类型和所有属性（包括大小）都被完整保留。

template<typename T>
void f(T& arr){
    std::cout << "size of arr is:" << sizeof(arr) << std::endl;
}

int main() {
    int arr[3] = {1, 2, 3};
    f(arr);
}
//打印结果：12

函数实参

在C++中不只是数组会退化为指针，函数类型也会退化为一个函数指针，我们对于数组类型推导的全部讨论都可以应用到函数类型推导和退化为函数指针上来。

#include <iostream>
#include <typeinfo>

// 一个简单的函数
void greeting() {
    std::cout << "Hello!" << std::endl;
}

// 案例 1: 按值传递 (会发生退化)
template<typename T>
void f_by_value(T func) {
    std::cout << "f_by_value: T is deduced as " << typeid(T).name() << std::endl;
    func(); // 可以像普通函数一样调用
}

// 案例 2: 按引用传递 (不发生退化)
template<typename T>
void f_by_reference(T& func) {
    std::cout << "f_by_reference: T is deduced as " << typeid(T).name() << std::endl;
    func();
}

int main() {
    // PFvvE 是 void(*)() 的 mangled name，即函数指针
    // FvvE 是 void() 的 mangled name，即函数类型
    // (具体名字可能因编译器而异)
    
    std::cout << "--- 传递函数名 greeting ---" << std::endl;
    f_by_value(greeting);      // (1)
    f_by_reference(greeting);  // (2)
    
    std::cout << "\n--- 传递 &greeting (显式取地址) ---" << std::endl;
    f_by_value(&greeting);     // (3)
}

/*
打印结果：
--- 传递函数名 greeting ---
f_by_value: T is deduced as PFvvE
Hello!
f_by_reference: T is deduced as FvvE
Hello!

--- 传递 &greeting (显式取地址) ---
f_by_value: T is deduced as PFvvE
Hello!
*/

1. f_by_value(greeting)
   • 发生了什么: 和数组一样，为了将 greeting 按值传递，编译器需要获取它的“值”。一个函数本身是代码段，不能被拷贝。它的“值”就是它在内存中的地址。
   • 退化: greeting (类型为 void()) 自动退化成一个指向它的指针 (类型为 void(*)())。
   • 类型推导: 模板看到传递过来的是一个 void(*)() 类型的指针，所以 T 被推导为 void(*)()。
   • 输出: T is deduced as ... (表示一个函数指针类型 void(*)())
2. f_by_reference(greeting)
   • 发生了什么: 同样，引用直接绑定到对象上。它不需要获取 greeting 的“值”。
   • 不退化: 引用直接绑定到 greeting 这个函数实体本身。
   • 类型推导: 为了让 T& 成功绑定到一个类型为 void() 的函数上，模板必须将 T 推导为函数类型本身，即 void()。参数的最终类型是 void(&)() (对函数的引用)。
   • 输出: T is deduced as ... (表示一个函数类型 void())
3. f_by_value(&greeting)
   • 发生了什么: 这里我们使用 & 运算符显式地获取了函数的地址，结果是一个 void(*)() 类型的指针。
   • 退化: 其实退化规则在这里也适用了，但因为我们已经显式取了地址，所以结果是完全一样的。f_by_value(greeting) 和 f_by_value(&greeting) 最终传递给函数的都是同一个指针值。
   • 类型推导: T 毫无疑问被推导为 void(*)()。

item2：理解auto类型推导

在Item1中，模板类型推导使用下面这个函数模板

template<typename T>
void f(ParmaType param);

和这个调用来解释：

f(expr);                        //使用一些表达式调用f

在f的调用中，编译器使用expr推导T和ParamType的类型。

当一个变量使用auto进行声明时，auto扮演了模板中T的角色，变量的类型说明符扮演了ParamType的角色。

类型说明符既不是指针也不是引用

这是最简单、最常见的情况，auto 自己就是一个独立的类型说明符。

推导规则：

1. 忽略初始化表达式的引用（&）属性。
2. 忽略初始化表达式的顶层 const 和 volatile 属性。
3. 最终推导出的类型是一个全新的、独立的值类型。

#include <iostream>

int main() {
    int x = 27;          // x 是 int
    const int cx = x;    // cx 是 const int
    const int& rx = x;   // rx 是 const int&，是 x 的一个别名

    // --- 开始推导 ---

    auto a = x;  // x 是 int。a 的类型被推导为 int。
                 // a 是 x 的一个全新副本。

    auto b = cx; // cx 是 const int。规则2生效，顶层 const 被忽略。
                 // b 的类型被推导为 int。b 也是一个副本。

    auto c = rx; // rx 是 const int&。规则1和2同时生效，引用和顶层 const 都被忽略。
                 // c 的类型被推导为 int。c 仍然是一个副本。

    a = 100; // 修改 a 不会影响 x
    b = 200; // 修改 b 不会影响 cx 或 x
    c = 300; // 修改 c 不会影响 rx 或 x

    std::cout << "x = " << x << std::endl;   // 输出: x = 27
    std::cout << "a = " << a << std::endl;   // 输出: a = 100
    std::cout << "b = " << b << std::endl;   // 输出: b = 200
    std::cout << "c = " << c << std::endl;   // 输出: c = 300

    // 如果想保留 const，需要自己加上
    const auto d = cx; // d 的类型被推导为 const int
    // d = 400; // 错误：不能给 const 变量赋值
}

在这种情况下，auto 总是产生一个非引用、非 const 的新副本（除非你自己加上 const）。

类型说明符是一个指针或非通用引用

这种情况包括 auto&, const auto&, auto* 等。

推导规则：

1. auto 会首先“匹配”初始化表达式的类型。
2. 引用和 const 属性不再被忽略，它们会参与到类型匹配中。
3. 编译器会根据 auto 旁边的修饰符（&, *, const）来最终确定类型。

#include <iostream>

int main() {
    int x = 27;
    const int cx = x;

    // --- 推导 auto& (左值引用) ---
    auto& a = x;  // x 是 int。auto 被推导为 int，所以 a 的类型是 int&。
                  // a 是 x 的别名。
    
    auto& b = cx; // cx 是 const int。auto 被推导为 const int，所以 b 的类型是 const int&。
                  // b 是 cx 的别名。
    
    // auto& c = 27; // 错误：不能将一个非常量左值引用绑定到右值 27。

    a = 50; // 修改 a 就是修改 x
    // b = 60; // 错误：b 是一个常量引用，不能通过它修改值。
    
    std::cout << "x after changing a: " << x << std::endl; // 输出: 50

    // --- 推导 const auto& (常量左值引用) ---
    const auto& d = x;  // x 是 int。auto 推导为 int，d 的类型是 const int&。
    const auto& e = cx; // cx 是 const int。auto 推导为 int，e 的类型是 const int&。
    const auto& f = 27; // 27 是右值。auto 推导为 int，f 的类型是 const int&。
                        // 常量左值引用可以绑定到右值。

    // --- 推导 auto* (指针) ---
    int* px = &x;
    const int* cpx = &x;

    auto* g = px;  // px 是 int*。auto 推导为 int，g 的类型是 int*。
    auto* h = cpx; // cpx 是 const int*。auto 推导为 const int，h 的类型是 const int*。
                   // 注意：这里的 const 是底层的（指向的内容是 const），它被保留了。
}

在这种情况下，auto 扮演的是一个“类型匹配者”的角色。&、* 和 const 都会被保留和尊重，推导结果更加“字面化”。

类型说明符是一个通用引用

这种情况特指 auto&&。它遵循特殊的引用折叠规则。

推导规则：

1. 如果初始化表达式是左值 (Lvalue)，auto 会被推导为 T&，最终类型为 T& &&，折叠为 T& (左值引用)。
2. 如果初始化表达式是右值 (Rvalue)，auto 会被推导为 T，最终类型为 T&& (右值引用)。

#include <iostream>

int main() {
    int x = 27;
    const int cx = x;

    // --- 推导 auto&& ---
    
    // 规则1：用左值初始化
    auto&& a = x;  // x 是一个 int 类型的左值。
                   // auto 被推导为 int&。
                   // a 的类型是 int& &&，折叠后为 int& (左值引用)。
                   // a 绑定到 x。

    auto&& b = cx; // cx 是一个 const int 类型的左值。
                   // auto 被推导为 const int&。
                   // b 的类型是 const int& &&，折叠后为 const int& (常量左值引用)。
                   // b 绑定到 cx。

    a = 99; // 可以修改，因为 a 是 int&
    // b = 100; // 错误，因为 b 是 const int&
    
    std::cout << "x after changing a: " << x << std::endl; // 输出: 99

    // 规则2：用右值初始化
    auto&& c = 27; // 27 是一个 int 类型的右值。
                   // auto 被推导为 int。
                   // c 的类型是 int&& (右值引用)。
                   // c 绑定到临时量 27。

    c = 101; // 可以修改右值引用的值
    std::cout << "c = " << c << std::endl; // 输出: 101
}

和顶层const，底层const结合：

#include <iostream>

int main() {
    int val = 10;
    
    const int* const x = &val; 
    
    auto a = x;     // 类型被推导为 const int* !
	
    /*
    注意第一点就说过的：
        当执行拷贝操作时:
        1. 顶层 const 可以忽略
        2. 底层 const 必须保持一致
    */
    
    std::cout << *a << std::endl; // 合法
    
    a++; // 合法！因为a的类型是const int*, 表示a指向的内容是const, 而a本身(地址)不是const
    
    //(*a)++; // 不合法！a指向的内容是const
}

auto类型推导和模板类型推导之间的区别

auto 类型推导假定花括号初始化代表 std::initializer_list

auto x = {1, 2, 3}; // x 的类型是 std::initializer_list<int>
auto y = {10};      // y 的类型是 std::initializer_list<int>
// auto z = {1, 2.0}; // 编译错误：初始化列表中的元素类型必须一致

#include <iostream>

template <typename T>
void func(T param) {
    // ...
}

template <typename T>
void func_ref(T& param) {
    // ...
}

template <typename T>
void func_fwd(T&& param) {
    // ...
}

int main() {
    // func({1, 2, 3});   // 编译错误！T 无法从 {1, 2, 3} 推导出来。
    // func_ref({1, 2, 3}); // 编译错误！T& 无法绑定到 {1, 2, 3}，也无法推导 T。
    // func_fwd({1, 2, 3}); // 编译错误！T&& 也无法从 {1, 2, 3} 推导出来。
}

为什么会这样？ 对于模板函数，{1, 2, 3} 是一个初始化列表，但它本身没有具体类型。它不是一个 std::initializer_list 对象，而是一个可以用来构造 std::initializer_list 对象或其他支持列表初始化的对象的语法结构。编译器无法仅凭 T 来确定 T 应该如何处理这个花括号列表。

但是，你可以显式地指定 std::initializer_list 类型：

template <typename T>
void process_list(std::initializer_list<T> list_param) {
    for (const auto& item : list_param) {
        std::cout << item << " ";
    }
    std::cout << std::endl;
}

process_list({1, 2, 3}); // 合法！T 被推导为 int。
                         // 因为函数参数类型明确要求 std::initializer_list<T>

item3：理解decltype

decltype 是 C++11 引入的一个关键字，用于在编译时推断并返回表达式的准确类型。与 auto 关键字不同，decltype 推断的类型会保留表达式的引用性（lvalue/rvalue）和 const/volatile 限定符，提供更精确的类型信息。

decltype 的基本用法

decltype(expression)

其中 expression 是一个有效的 C++ 表达式。decltype 会推断这个表达式的类型，但 不会实际评估 这个表达式。

int x = 0;
decltype(x) y = x; // y 的类型是 int

const int& rx = x;
decltype(rx) ry = rx; // ry 的类型是 const int&

const int cx = 0;
decltype(cx) cy = cx; // cy 的类型是 const int

int* ptr = &x;
decltype(ptr) p2 = ptr; // p2 的类型是 int*

int arr[5];
decltype(arr) arr2; // arr2 的类型是 int[5]

推断表达式的类型

这是 decltype 最强大也最容易混淆的地方。当 expression 不是变量名，而是一个更复杂的表达式时，decltype 的行为取决于表达式是 左值 (lvalue) 还是 右值 (rvalue)。

• 如果表达式是一个左值 (lvalue)，decltype 推断出的类型是 T& (引用类型)，并保留 const/volatile 限定符。
• 如果表达式是一个右值 (rvalue)，decltype 推断出的类型是 T (非引用类型)，并保留 const/volatile 限定符

int i = 42;

// 情况 1: 变量名 (总是左值)
decltype(i) a = i; // a 的类型是 int (因为 i 是一个变量名，而不是一个表达式，decltype(i) 直接获取i的声明类型)

// 情况 2: 加括号的变量名 (强制为左值表达式)
decltype((i)) b = i; // b 的类型是 int& (因为 (i) 是一个左值表达式)
b = 100; // i 变为 100

// 情况 3: 算术表达式 (通常是右值)
decltype(i + 1) c = i + 1; // c 的类型是 int (i + 1 是一个右值表达式)

// 情况 4: 解引用操作 (通常是左值)
int* p = &i;
decltype(*p) d = *p; // d 的类型是 int& (*p 是一个左值表达式)
d = 200; // i 变为 200

// 情况 5: 函数调用
int& get_ref() { return i; }
int get_val() { return i; }

decltype(get_ref()) e = get_ref(); // e 的类型是 int& (get_ref() 返回左值引用)
decltype(get_val()) f = get_val(); // f 的类型是 int (get_val() 返回右值)

const int ci = 0;
decltype((ci)) g = ci; // g 的类型是 const int& ((ci) 是一个 const 左值表达式)

struct MyStruct { int x; };
MyStruct ms;
decltype(ms.x) h = ms.x;       // h 的类型是 int (ms.x 作为变量名，直接获取类型)
decltype((ms.x)) k = ms.x;     // k 的类型是 int& ((ms.x) 作为左值表达式)

在泛型编程中推断返回类型

当函数的返回类型依赖于其模板参数时，decltype 和尾随返回类型语法非常有用。

template<typename Container, typename Index>
auto f(Container& c, Index i) -> decltype(c[i]){
    c[i]++;
    return c[i];
}

int main() {
    std::vector<float> v(10);
    f(v, 1) = 10;
}

这样写是正确的！函数f()指定了返回值decltype(c[i])，类型是float&。对于 std::vector<float>，operator[] 返回的是 float& (一个对元素的引用)。因此，decltype(c[i]) 在这里会被推断为 float&。这意味着函数 f 返回的是一个 float 类型的引用。

结果将v[1]的值变为10

注意！如果这样写就是错误的！

template<typename Container, typename Index>
auto f(Container& c, Index i){
    c[i]++;
    return c[i];
}

int main() {
    std::vector<float> v(10);
    //f(v, 1) = 10;	// 错误！
}

因为函数f()没有指明返回值类型，auto自动推导忽略了&，返回值类型变为float

此时f(v, 1) = 10就相当于给一个右值赋值，肯定是错误的

还有一种写法：使用decltype(auto)

template<typename Container, typename Index>
decltype(auto) f(Container& c, Index i){
    c[i]++;
    return c[i];
}


int main() {
    std::vector<float> v(10);
    f(v, 1) = 10;
}

我们可以这样解释它的意义：auto说明符表示这个类型将会被推导，decltype说明decltype的规则将会被用到这个推导过程中。

运用了decltype规则推导，则&就会被保留下来，所以返回值类型成了float &

decltype(auto)也可用于普通变量的类型推导

int x = 10;
const int cx = 11;
decltype(auto) a = cx;
auto b = cx;
//a++;	// 错误！
b++;	//正确！

decltype(auto) a = cx;表示使用decltype的规则推导，则const被保留，所以a的类型是const int，不能被修改

再看一个例子：

template<typename Container, typename Index>
decltype(auto) f(Container&& c, Index i){
    return c[i];
}

// 把很多字符串放到一个队列里
std::deque<std::string> makeStringDeque(); 

int main() {
    auto s = f(makeStringDeque(), 5);// 要获取第五个字符串
}

注意！这里的函数f()中的Container&& c必须使用通用引用&&！

因为函数makeStringDeque()的返回值是一个右值！

itme5：优先考虑auto而非显式类型声明

在声明变量时，尽可能使用 auto 关键字让编译器去推断类型，而不是自己手动写出完整的类型。

例如：

// 传统方式
int x = 0;
std::vector<int>::iterator it = myVec.begin();

// 现代 C++ 推荐方式
auto x = 0; // 编译器推断 x 为 int
auto it = myVec.begin(); // 编译器推断 it 为 std::vector<int>::iterator

为什么这样做是更好的选择？

1. 正确性

   这是使用 auto 最重要的原因。auto 可以帮助你避免一些难以发现的类型错误。

   • 保证变量被初始化

     int x; // 未初始化，值是未定义的 (UB)
     Widget w; // 调用了 Widget 的默认构造函数
     

     如果使用 auto，就必须提供一个初始值，因为编译器需要根据这个初始值来推断类型。这从语法上就杜绝了“未初始化”的变量。

     auto x; // 编译错误！必须初始化
     auto x = 0; // 正确，x 被初始化为 0，类型为 int
     

   • 避免写错复杂的类型

     当类型变得复杂时，手动书写不仅繁琐，而且容易出错。

     // 手动声明一个处理 int 的 lambda，类型复杂且无法写出
     // std::function<bool(int, int)> f = [](int a, int b){ return a > b; }; 
     // 这其实是类型擦除，不是 lambda 的原始类型
              
     // 使用 auto 就简单而精确
     auto greater = [](int a, int b) { return a > b; }; // greater 的类型就是这个 lambda 的真实类型
              
     

     使用 auto，编译器会保证变量的类型是绝对正确的，你不会因为手误或理解偏差而写错类型。

   • 避免无意的类型转换（性能陷阱）

     这是一个非常微妙但重要的点。有时候，你显式声明的类型可能不是你想要的那个，从而导致了不必要的类型转换，甚至影响性能。

     书中最经典的例子是 std::vector<bool>。由于 C++ 标准对 vector<bool> 做了特化，它的 operator[] 返回的不是一个 bool&，而是一个代理对象（proxy object），通常是 std::vector<bool>::reference 类型。这个代理对象可以隐式转换为 bool。

     std::vector<bool> features(getFeatures());
              
     // 显式声明为 bool
     bool highPriority = features[5]; // 1. operator[] 返回一个代理对象
                                      // 2. 代理对象隐式转换为 bool
                                      // 3. bool 被用来初始化 highPriority
              
     // 使用 auto
     auto highPriority = features[5]; // highPriority 的类型被正确推断为 std::vector<bool>::reference
                                      // 这里没有发生从代理对象到 bool 的转换
              
     

     在这个例子中，显式声明为 bool 会强制发生一次类型转换，生成一个临时的 bool 值。而使用 auto 则直接得到了代理对象本身，避免了这次转换。虽然在这个特定场景下性能差异可能不大，但在更复杂的代理模式中（如表达式模板），这种差异可能是巨大的。auto 能确保你得到的是表达式“真正”的类型。

2. 可维护性

   使用 auto 可以让代码更容易维护和重构。

   想象一个函数，它返回一个特定类型的值：

   // a_library.h
   std::map<std::string, int> getSomeMap();
        
   // your_code.cpp
   std::map<std::string, int> myMap = getSomeMap();
   

   现在，库的作者决定优化 getSomeMap，让它返回一个 std::unordered_map，因为哈希表的性能更好。

   // a_library.h (after change)
   std::unordered_map<std::string, int> getSomeMap();
   

   你的代码 your_code.cpp 会编译失败，因为类型不匹配了。你必须手动去修改所有调用 getSomeMap 的地方。

   但如果你一开始就使用了 auto：

   // your_code.cpp (with auto)
   auto myMap = getSomeMap();
   

   当 getSomeMap 的返回类型改变时，myMap 的类型也会自动随之改变。你的代码无需任何修改就能正常工作。这大大简化了代码的重构过程。

item6：auto推导若非己愿，使用显式类型初始化惯用法

auto 推断出的类型并非总是你想要的。

auto 的工作方式是忠实地、精确地推断出初始化表达式的类型。但在某些情况下，表达式的“真实”类型可能是一个我们不希望直接持有的类型，比如一个代理对象（Proxy Object）。

在这些情况下，我们想要的不是表达式本身的类型，而是它可以隐式转换成的那个目标类型。

经典案例：std::vector<bool> 的代理对象

这个例子在 Item 5 的讨论中也提到过，但在 Item 6 中是核心。

C++ 标准库对 std::vector<bool> 进行了空间优化特化。为了节省空间，它内部并不存储 bool（通常占 1 字节），而是用一个比特位（bit）来表示一个布尔值。

这个优化的代价是 operator[] 不能返回一个 bool& (因为 C++ 中没有“比特位的引用”这种东西)。取而代之，它返回一个代理对象，类型为 std::vector<bool>::reference。这个代理对象表现得像一个 bool&，它重载了赋值运算符和向 bool 的类型转换函数。

std::vector<bool> features(getFeatures());

auto highPriority = features[5]; // highPriority 的类型是什么？

根据 auto 的推断规则，highPriority 的类型被精确地推断为 std::vector<bool>::reference。

在大多数情况下，这没问题，因为 std::vector<bool>::reference 可以隐式转换为 bool。但有一种情况是致命的：当 std::vector<bool> 是一个临时对象时。

代理对象 std::vector<bool>::reference 内部通常包含一个指向 vector 内部数据块的指针和一个偏移量。如果这个 vector 是临时的，它在表达式结束时就会被销毁。

std::vector<bool> makeVec() {
    return {false, true, false, true, false, true};
}

// ...

auto p = makeVec()[5]; // 危险！

这里发生了什么？

1. makeVec() 返回一个临时的 std::vector<bool> 对象。
2. [5] 对这个临时对象调用，返回一个 std::vector<bool>::reference 代理对象。
3. 这个代理对象 p 内部持有的指针指向了那个临时的 vector。
4. 在分号处，完整的表达式结束，临时的 vector 被销毁。
5. 现在，p 变成了一个悬空引用 (dangling reference)！它内部的指针指向了一块已经被释放的内存。任何后续对 p 的使用都是未定义行为（Undefined Behavior）。

在这个场景下，我们真正想要的不是代理对象 std::vector<bool>::reference，而是一个纯粹的 bool 值。

如果用的是bool p，那就会为p专门开辟一块1B的内存，并把零时变量里的值拷贝到p的内存中。

而auto不同的是，p的实际类型是一个std::vector<bool>::reference 代理对象，只是将p的指针指向了临时变量的那块内存。而临时对象在分号之后就已经销毁了。

怎么验证？

#include <iostream>
#include <vector>
std::vector<bool> makeVec() {
    return {false, true, false, true, false, true};
}

int main() {
    auto p = makeVec()[5]; 
    std::cout << p << std::endl;// 打印结果会是什么？
}

可以看到，打印的结果并不固定。这是因为p的指针指向的那块内存已经被释放了，不是true，已经是未定义的内存了。

怎么修改？

#include <iostream>
#include <vector>
std::vector<bool> makeVec() {
    return {false, true, false, true, false, true};
}

int main() {
    auto p = static_cast<bool> (makeVec()[5]); // 安全！
    // 等价于 bool p = static_cast<bool> (makeVec()[5]);
    std::cout << p << std::endl;
}

item7：区别实用()和{}创建对象

{}创建对象的特点

{} 初始化虽然强大，但它有一个“霸道”的特性：只要有可能，它就会优先匹配接收 std::initializer_list 的构造函数。这导致了 {} 和 () 之间三个主要区别：

1. 对 std::initializer_list 的“贪婪”匹配：这是最令人惊讶和最需要注意的区别。
2. 对窄化转换（Narrowing Conversions）的禁止：这是 {} 的一个重要安全特性。
3. 对“最令人烦恼的解析”（Most Vexing Parse）的免疫：这是 {} 的一个便利之处。

对 std::initializer_list 的“贪婪”匹配

这是 Item 7 的核心。规则是：当使用 {} 进行对象构造时，如果类有一个或多个接收 std::initializer_list 的构造函数，编译器会极其强烈地（甚至不惜进行类型转换）优先选择这些构造函数。

我们来看一个经典的例子。假设有一个 Widget 类：

class Widget {
public:
    // "普通"构造函数
    Widget(int i, bool b) { /* ... */ } 
    Widget(int i, double d) { /* ... */ }

    // 接收 initializer_list 的构造函数
    Widget(std::initializer_list<long double> il) { /* ... */ }

    // ... 其他函数
};

现在，我们用不同的方式来创建对象：

Widget w1(10, true); // 使用 ()
// 匹配过程：
// 1. 寻找 Widget(int, bool)，完美匹配！
// 结果：调用 Widget(int, bool) 构造函数。这符合我们的直觉。

Widget w2{10, true}; // 使用 {}
// 匹配过程：
// 1. 优先寻找接收 std::initializer_list 的构造函数。找到了 Widget(std::initializer_list<long double> il)。
// 2. 检查初始化列表 {10, true} 中的元素能否转换为 long double？
//    - 10 (int) -> 10.0 (long double)，可以。
//    - true (bool) -> 1.0 (long double)，可以。
// 3. 转换是合法的，于是**选择此构造函数。
// 结果：调用 Widget(std::initializer_list<long double>) 构造函数。这可能完全不是你的本意！

Widget w3(10, 5.0); // 使用 ()，调用 Widget(int, double)
Widget w4{10, 5.0}; // 使用 {}，仍然调用 Widget(std::initializer_list<long double>)

为什么会这样？

编译器的重载解析过程在遇到 {} 初始化时，会有一个特殊的“特权阶段”。它会先检查有没有 std::initializer_list 版本的构造函数。只要初始化列表中的实参类型能够（不发生窄化转换地）被隐式转换为 std::initializer_list 中指定的类型，编译器就会毫不犹豫地选择它，而完全忽略其他可能更匹配的“普通”构造函数。

这个特性对于像 std::vector 这样的容器类来说，是符合直觉的：

std::vector<int> v1{10, 20}; // 调用 initializer_list 构造函数，v1 包含两个元素：10 和 20。
std::vector<int> v2(10, 20); // 调用普通构造函数，v2 包含十个元素，每个元素的值都是 20。

在这里，{} 和 () 的行为差异是设计好的，也是我们想要的。但当这个规则应用到像上面 Widget 这样的类时，就会产生意外。

一个特殊情况：如果使用 {} 时，实参类型到 std::initializer_list 的类型转换会导致窄化转换，那么编译器就会放弃 std::initializer_list 构造函数，转而进行正常的重载解析。

禁止窄化转换 (Narrowing Conversions)

窄化转换是指一个值从一种类型转换到另一种类型时，可能会丢失精度或超出目标类型的表示范围。例如，double 转 int，或者一个大的 int 转 char。

使用 () 初始化的传统方式是允许窄化转换的（编译器通常只会给一个警告）。而 {} 初始化则在编译期就禁止这种转换，直接导致编译错误。

double x = 1.2, y = 3.4, z = 5.6;

int sum1(x + y + z); // 合法，但有风险。x+y+z 的结果是 10.2，被截断为 10 赋给 sum1。
                     // 编译器可能会给一个警告。

int sum2{x + y + z}; // 编译错误！
                     // double -> int 是一种窄化转换，{} 初始化不允许。

注：

g++ -std=c++14 main.cpp -o main会编译成功，只是会弹出warning

开启严格编译模式g++ -std=c++14 -pedantic-errors main.cpp -o main则会输出error

免疫“最令人烦恼的解析” (Most Vexing Parse)

这是 C++ 语言中一个经典的语法歧义问题。当你想创建一个默认构造的对象时，如果你不小心加上了括号，它就会被编译器解析成一个函数声明。

// 你的意图：创建一个名为 w 的 Widget 对象，使用默认构造函数。
Widget w(); // 糟糕！这不是对象声明！
            // 这是声明一个名为 w 的函数，该函数不接受参数，返回一个 Widget 对象。
            // 这就是 "Most Vexing Parse"。

为了正确地默认构造一个对象，你必须省略括号：

Widget w; // 正确。调用 Widget 的默认构造函数。

而使用 {} 初始化则完全没有这个歧义问题：

Widget w{}; // 正确且清晰。创建一个名为 w 的 Widget 对象，使用默认构造函数。

因此，在需要调用默认构造函数时，使用 {} 是一种更清晰、更不容易出错的选择。

item8: 优先考虑nullptr而非0和NULL

在 C++11 之前，我们用 0 或者一个宏 NULL 来表示空指针。这两种方式都存在一个根本性的缺陷：它们都不是真正的指针类型。0 是一个 int，而 NULL 通常只是一个被宏定义为 0 或者 ((void*)0) 的东西。这种类型上的模糊性会导致函数重载决议（overload resolution）出现意外。

C++11 引入了一个新的关键字 nullptr，它是一个真正的“空指针常量”，拥有自己独立的类型 std::nullptr_t，从而完美地解决了上述问题。

为什么0和NULL不好？

问题的根源在于 0 和 NULL 的类型歧义。让我们通过一个经典的函数重载例子来理解这个陷阱。

假设我们有三个重载函数，分别用于处理 int、bool 和指针：

void f(int i) {
    std::cout << "Called f(int)" << std::endl;
}

void f(bool b) {
    std::cout << "Called f(bool)" << std::endl;
}

void f(void* ptr) {
    std::cout << "Called f(void*)" << std::endl;
}

现在，我们尝试用 0 和 NULL 来调用我们期望的指针版本 f(void*)：

f(0); // 我们期望调用哪个版本？

f(NULL); // 我们又期望调用哪个版本？

使用 0 的问题：

0 的字面量类型是 int。根据 C++ 的重载决议规则，编译器会选择最匹配的版本。

• f(0) 传入的是一个 int。
• f(int) 是一个完美匹配。
• f(bool) 需要 int->bool 转换。
• f(void*) 需要 int(空指针常量)->void* 转换。

完美匹配的优先级最高。 因此，f(0) 会调用 f(int)！

输出:

Called f(int)

这完全违背了程序员“我想传递一个空指针”的意图。这是一个非常隐蔽且危险的 Bug。

使用 NULL 的问题

NULL 只是一个宏，它的具体定义是实现相关的。通常，它被定义为以下两种之一：

#define NULL 0
// 或者
#define NULL 0L
// 或者在 C++ 中，有时是
#define NULL ((void*)0) 

• 如果 NULL 被定义为 0 或 0L：那么 f(NULL) 就等同于 f(0) 或 f(0L)。它依然会因为类型匹配问题而去调用 f(int)（或者一个 f(long) 的重载），而不是我们想要的指针版本。
• 如果 NULL 被定义为 ((void*)0)：情况会好一些。f(NULL) 会正确调用 f(void*)。但是，这种定义方式本身也有问题，比如它不能被用于需要整型类型的上下文，而且宏本身在现代 C++ 中也是不被推荐的。

最糟糕的是，你无法确定 NULL 在你的平台和编译器上到底是什么，这使得依赖 NULL 的代码不具备良好的可移植性和可预测性。

解决方案：nullptr

C++11 引入 nullptr 来一劳永逸地解决这个问题。

• nullptr 是一个关键字，不是宏。
• 它的类型是 std::nullptr_t。
• std::nullptr_t 类型可以隐式转换为任何类型的指针（如 int*, Widget*, std::string* 等）。
• std::nullptr_t 不能隐式转换为整型（int, bool 除外，它可转换为 false）。

现在，我们用 nullptr 来调用上面的重载函数：

f(nullptr);

重载决议过程如下：

• nullptr 的类型是 std::nullptr_t。
• f(int): std::nullptr_t 无法转换为 int。此路不通。
• f(bool): std::nullptr_t 可以转换为 bool (false)。这是一个合法的转换。
• f(void*): std::nullptr_t 可以转换为 void*。这是一个合法的转换。

现在我们有了两个合法的转换。但是，从 std::nullptr_t 到指针类型的转换被认为是比到 bool 更好的匹配。因此，编译器会毫不犹豫地选择指针版本。

输出：Called f(void*)

这完全符合我们的意图！nullptr 解决了类型歧义，让代码的行为变得正确和可预测。

nullptr的其他优势

当你在模板中使用 0 或 NULL 时，模板类型推导可能会将其推导为整型（int 或 long），这通常会导致编译错误或非预期的行为。而 nullptr 的类型是 std::nullptr_t，模板可以正确地处理它。

template<typename F, typename T>
void forwarder(F f, T arg) {
    f(arg);
}

forwarder(f, 0);       // T 被推导为 int，调用 f(int)
forwarder(f, NULL);    // T 可能被推导为 int 或 long，调用 f(int)
forwarder(f, nullptr); // T 被推导为 std::nullptr_t，正确调用 f(void*)

规则很简单： 在现代 C++ 代码中，永远不要使用 0 或 NULL 来表示空指针。始终使用 nullptr。这是一个没有例外、可以无脑遵守的规则。

item9：优先考虑别名声明而非typedef

这个条款是 C++11 引入的一项重要的语言改进。它建议我们在为类型创建别名（alias）时，放弃传统的 typedef 关键字，转而使用新的 using 语法。虽然 typedef 仍然可用且有效，但 using 提供了更好的可读性，并且能够完成 typedef 无法完成的任务——别名模板（alias templates）

对于更复杂的类型，比如函数指针，using 的可读性优势更加明显。

使用 typedef 创建函数指针别名:

// FP 是一个指向“接受 int 和 const std::string&，返回 void”的函数的指针类型
typedef void (*FP)(int, const std::string&);

使用 using 创建函数指针别名:

// FP 是一个指向“接受 int 和 const std::string&，返回 void”的函数的指针类型
using FP = void (*)(int, const std::string&);

这种写法将别名 FP 和它所代表的复杂类型清晰地分开了，FP 在左边，类型在右边，一目了然。

using 可以被模板化，从而创建别名模板，而 typedef 不能

场景：我们想要一个自定义的 std::vector

假设我们正在开发一个项目，需要频繁使用一个带有自定义内存分配器 MyAlloc 的 std::vector。我们希望创建一个别名，让 MyVector<T> 就代表 std::vector<T, MyAlloc<T>>。

使用 typedef 的尝试（失败的）: 你可能会想这么写，但这在语法上是不合法的：

template<typename T>
typedef std::vector<T, MyAlloc<T>> MyVector; // 编译错误！typedef 不能被模板化

C++11 的别名模板完美地解决了这个问题。

template<typename T>
using MyVector = typename std::vector<T, MyAlloc<T>>;

// 使用时：
MyVector<int> myVec; // 简单、直观，就像使用普通模板一样

item10：优先考虑限域枚举而非未限域枚举

这个条款强烈建议在 C++11 及以后的代码中，使用新的 enum class (或 enum struct) 来代替旧的 enum。这是一个关于类型安全、作用域控制和代码清晰度的重要改进。

传统的 C-style enum (现在称为不限作用域枚举 Unscoped Enum) 存在几个严重的设计缺陷，这些缺陷常常导致命名冲突和类型安全漏洞。C++11 引入的作用域内枚举 (Scoped Enum)，通过 enum class 关键字，完美地修复了这些问题。

不限作用域枚举的三大缺陷

1. 枚举成员污染所在作用域

不限作用域枚举的枚举成员会“泄漏”到其定义所在的整个作用域中，就像普通变量一样。

// a_library.h
enum Color { Red, Green, Blue };

// my_code.h
enum TrafficLight { Green, Yellow, Red }; // 编译错误！

int main() {
    Color c = Red; // 是哪个 Red？
    TrafficLight t = Green; // 是哪个 Green？
}

这段代码无法编译，因为 Red 和 Green 在同一个作用域（这里是全局作用域）中被重复定义了。为了解决这个问题，程序员们不得不使用各种变通方法，比如给枚举成员加上前缀：

enum Color { COLOR_RED, COLOR_GREEN, COLOR_BLUE };
enum TrafficLight { TRAFFIC_LIGHT_GREEN, TRAFFIC_LIGHT_YELLOW, TRAFFIC_LIGHT_RED };

这种方法很丑陋，而且完全是手动劳动，容易出错。

2. 隐式转换为整型，破坏类型安全

不限作用域枚举的成员可以被隐式地转换为任何整型（int, char, unsigned int 等），但反过来不行（从整型到枚举需要显式转换）。

这种单向的隐式转换会破坏类型安全，导致一些在逻辑上毫无意义的操作能够通过编译。

enum Color { Red, Green, Blue };
enum AlertLevel { Low, Medium, High };

Color c = Red;         // c 的值是 0
AlertLevel a = High;   // a 的值是 2

// 编译通过，但逻辑上毫无意义！
// 你在比较一个颜色和一个警报级别。
if (c < a) { 
    // ... 这个 if 语句会执行，因为 0 < 2
    std::cout << "Color is less than AlertLevel!" << std::endl;
}

编译器不会阻止你这样做，因为它看到的只是两个整数在比较。这可能导致非常隐蔽的逻辑错误。你本意是想比较同类型的东西，却因为隐式转换，错误地比较了两个完全不相关的值。

3. 难以进行前向声明

前向声明（Forward Declaration）是C++中的一种技术，用于在声明某个实体（通常是类、函数、变量等）的名称而无需提供其详细定义。 前置声明的目的是为了告诉编译器某个实体的存在，以便在稍后的代码中引用它，而不必在声明的地方提供完整的定义。 这可以提高编译速度和减少编译依赖性

前向声明在 C++ 中对于减少编译依赖、加快编译速度非常重要。你想在头文件中只声明一个枚举，而在源文件中定义它。

对于不限作用域枚举，默认情况下无法进行前向声明。因为编译器不知道这个 enum 底层应该用多大的整型来存储（是 int? char? unsigned int?）。

enum Color; // 编译错误！编译器不知道 Color 的大小。

虽然 C++11 之后，你可以为不限作用域枚举指定底层类型，从而让它能够被前向声明：

// a.h
enum Color : unsigned char; // OK in C++11
void use_color(Color c);

// a.cpp
enum Color : unsigned char { Red, Green, Blue };
void use_color(Color c) { /* ... */ }

但这需要你手动指定类型，而且并没有解决前两个核心缺陷。

作用域内枚举

C++11 的 enum class (或者它的同义词 enum struct) 干净利落地解决了上述所有问题。

枚举成员被严格限定在枚举的作用域内

enum class 的成员不会泄漏到外部作用域。你必须通过 枚举名::成员名 的方式来访问它们。

// a_library.h
enum class Color { Red, Green, Blue };

// my_code.h
enum class TrafficLight { Green, Yellow, Red }; // 完全没问题！

int main() {
    // 必须使用作用域解析符::
    Color c = Color::Red;
    TrafficLight t = TrafficLight::Green;

    // 下面的代码无法编译，因为 Red 和 Green 不在全局作用域中
    // Color c2 = Red; // 错误！
    
    // 不同枚举的同名成员不会冲突
    if (c == Color::Red && t == TrafficLight::Red) {
        // ...
    }
}

强类型，禁止隐式转换为整型

弱、强类型指的是语言类型的系统的类型检查的严格程度。弱类型相对于强类型来说类型检查更不严格，比如说允许变量类型的隐式转换，允许强制类型转换等等。强类型语言一般不允许这么做。

enum class 是强类型的。它的值不能被隐式地转换为整型。

enum class Color { Red, Green, Blue };       // Red 的值是 0
enum class AlertLevel { Low, Medium, High }; // High 的值是 2

Color c = Color::Red;
AlertLevel a = AlertLevel::High;

// if (c < a) { ... } // 编译错误！
// 错误信息：no match for ‘operator<’ (operand types are ‘Color’ and ‘AlertLevel’)

编译器现在可以帮你捕捉到这种逻辑错误了。如果你真的需要获取其底层的整数值（比如用于打印或序列化），你必须进行显式的类型转换，这表明了你的真实意图。

int colorValue = static_cast<int>(c); // 显式转换，OK
std::cout << colorValue << std::endl; // 输出 0

天生支持前向声明

enum class 的底层类型在 C++11 标准中默认为 int。因为它的底层类型是确定的，所以它可以被轻松地前向声明。

// my_widget.h
enum class Color; // OK！编译器知道它的大小（默认为 int）
void setBackgroundColor(Color c);

你也可以像不限作用域枚举一样，手动指定它的底层类型，这在需要精确控制内存布局或与 C API 交互时非常有用。

// 使用 1 字节存储
enum class Status : std::uint8_t {
    Good,
    Warning,
    Error
};

在 C++11 或更高版本的代码中，无条件地优先使用 enum class。它更安全、更清晰、更健壮。只有在极少数需要与旧的 C API 交互，而那个 API 又需要一个可以隐式转换为 int 的枚举类型时，你才可能需要退回到使用不限作用_域枚举。在所有其他情况下，enum class 都是更好的选择。

item11：优先考虑使用deleted函数而非使用未定义的私有声明

有时，我们不希望某些函数被调用。最经典的例子就是禁止类的拷贝。C++ 编译器会为我们自动生成一些函数（所谓的“特殊成员函数”），比如拷贝构造函数和拷贝赋值运算符。如果我们的类设计（例如，管理着独占资源，像文件句柄或网络套接字）不允许拷贝，我们就必须阻止编译器生成这些函数，并禁止任何人调用它们。

在 C++11 之前和之后，我们有两种方法来做这件事，而 C++11 的 = delete 是一个全方位的优越选择。

私有的未定义函数

在 C++11 出现之前，禁止一个成员函数（特别是拷贝构造/赋值）的标准做法是：

1. 将该函数声明为 private。
2. 只声明，不定义（不提供函数体实现）。

例子：一个不可拷贝的 Widget 类

class Widget {
private:
    // 1. 声明为 private
    // 2. 不提供定义 (no implementation)
    Widget(const Widget&);
    Widget& operator=(const Widget&);

public:
    Widget() = default;
    // ... 其他接口
};

这种方法是如何工作的？

它利用了两层防护：

1. 对于外部代码：当外部代码试图拷贝 Widget 对象时，例如 Widget w2 = w1;，编译器会检查访问权限。因为它发现拷贝构造函数是 private 的，所以会立即给出一个编译期错误 (compile-time error)。这是我们想要的效果。
2. 对于内部代码 (成员函数或 friend 类)：如果一个 Widget 的成员函数或友元函数试图拷贝 Widget 对象，它有权限访问 private 成员，所以编译会通过。但是，由于我们没有提供函数的定义，程序在链接阶段会找不到这个函数的实现，从而导致一个链接期错误 (link-time error)，通常是 “undefined reference to Widget::Widget(const Widget&)“。

这种方法的缺陷：

• 错误信息不友好且滞后：链接期错误通常比编译期错误更难排查。它发生在编译过程的最后阶段，而且错误信息可能不如编译器错误那样直接指向出错的调用代码行。
• 适用范围有限：这种技巧只能用于类的成员函数。它无法禁止一个非成员函数（自由函数）或一个特定的模板实例化。
• 意图不明确：private 的本意是“封装实现细节”，而不是“禁止使用”。这是一种“绕路”的技巧（idiom），而不是直接的语言特性。

=delete删除函数

C++11 引入了一种全新的、更直接的语法来禁止函数的使用：在函数声明后加上 = delete;。

= delete; 的含义：这个函数是被删除的。它存在，但不能以任何方式被调用。任何试图调用它的代码都会导致一个编译期错误。

class Widget {
public:
    // 显式地将它们声明为 public（习惯做法）然后删除
    Widget(const Widget&) = delete;
    Widget& operator=(const Widget&) = delete;

    Widget() = default;
    // ... 其他接口
};

• 注意：被删除的函数通常声明为 public。这是一种好的实践，因为客户端代码通常会先检查 public 接口。当它找到这个函数但发现它被删除了，编译器会立即给出一个清晰的错误信息。如果声明为 private，访问控制的错误信息可能会先于“函数被删除”的错误信息出现。

这种方法是如何工作的？

非常简单直接：任何代码——无论是外部代码、成员函数还是友元函数——只要试图调用一个被 delete 的函数，都会立即得到一个清晰的编译期错误。编译器会明确告诉你：“你正在尝试使用一个已被删除的函数”。

=delete可以用于任何函数，而不仅仅是成员函数

这是 = delete 的一个巨大优势。你可以删除任何函数，包括非成员函数。

场景：假设你有一个函数 isLucky(int)，但你不想让它被 bool 或 char 类型的参数调用，因为这种隐式转换可能会隐藏 bug。

bool isLucky(int number); // 我们想要这个版本

// 禁止传入 bool，因为 true/false 转换成 1/0 的意义可能不明确
bool isLucky(bool b) = delete;

// 禁止传入 char，防止不小心传入一个字符
bool isLucky(char c) = delete; 

int main() {
    isLucky(42);    // OK
    isLucky(true);  // 编译错误！尝试使用一个被删除的函数
    isLucky('a');   // 编译错误！
}

=delete可以用于禁止特定的模板实例化

这是 = delete 最强大的功能之一。你可以有一个通用的函数模板，然后显式地删除你不希望支持的特定类型实例化版本。

场景：你有一个处理指针的模板，但你希望禁止用户传入 void*（不安全）或 char*（可能是 C 风格字符串，应该用 std::string 处理）。

template<typename T>
void processPointer(T* ptr) {
    // ... 对有类型的指针进行处理
}

// 显式删除 void* 版本
template<>
void processPointer<void>(void* ptr) = delete;

// 显式删除 char* 版本
template<>
void processPointer<char>(char* ptr) = delete;

// 显式删除 const char* 版本
template<>
void processPointer<const char>(const char* ptr) = delete;

int main() {
    int x = 10;
    processPointer(&x);          // OK

    void* p = &x;
    processPointer(p);           // 编译错误！

    const char* str = "hello";
    processPointer(str);         // 编译错误！
}

总结

最终规则：

在 C++11 及以后的代码中，当你需要禁止一个函数的使用时，永远优先使用 = delete。它更安全、更清晰、功能更强大、适用范围更广。私有未定义函数的方法已经是一种过时的技术，应该在现代 C++ 代码中被完全取代。

item12：使用override声明重写函数

没有 override 的世界有多危险？

在 C++11 之前，如果你想重写一个虚函数，你只需要在派生类中声明一个和基类虚函数签名（函数名、参数列表、const 属性等）完全相同的函数即可。

这听起来简单，但“完全相同”这个要求非常脆弱，很容易在不经意间被打破，而编译器却不会给你任何警告。

以下是几种常见的“意外”：

函数名拼写错误

class Base {
public:
    virtual void doWork() { /* ... */ }
};

class Derived : public Base {
public:
    // 程序员的意图是重写，但不小心打错了字
    virtual void doWrok() { /* ... */ } // "Work" -> "Wrok"
};

结果：这段代码可以完美编译。但 Derived::doWrok 并没有重写 Base::doWork，它只是一个全新的、与基类无关的虚函数。当你通过基类指针调用 doWork 时，永远不会执行到派生类的版本，多态性被悄无声息地破坏了。

const 属性不匹配

class Base {
public:
    virtual void doWork() const { /* ... */ }
};

class Derived : public Base {
public:
    // 基类是 const 成员函数，这里忘记加 const
    virtual void doWork() { /* ... */ }
};

结果：编译通过，但 Derived::doWork 并没有重写 Base::doWork，因为它们的 const 属性不同。

基类函数签名变更

假设一开始代码是正确的：

// in Base.h
class Base {
public:
    virtual void doWork() { /* ... */ }
};

// in Derived.h
class Derived : public Base {
public:
    virtual void doWork() { /* ... */ } // 正确重写
};

后来，Base 类的维护者决定给 doWork 函数增加一个参数，并提供默认值以保持向后兼容：

// in Base.h (modified)
class Base {
public:
    virtual void doWork(int param = 0) { /* ... */ } // 签名变了！
};

结果：Derived::doWork() 现在不再重写任何基类函数了！它变成了一个独立的函数。你的整个项目仍然可以编译，但所有依赖于 doWork 多态性的地方都会开始出现奇怪的、错误的行为。

解决方案：override 关键字

C++11 的 override 完美地解决了以上所有问题。它告诉编译器：“我明确地声明，这个函数必须重写一个基类的虚函数。请帮我检查一下！”

我们用 override 来改写上面的例子：

class Base {
public:
    virtual void doWork() const { /* ... */ }
};

class Derived : public Base {
public:
    // 程序员犯了两个错误：拼写错误 + 忘记 const
    virtual void doWrok() override { /* ... */ } 
};

现在，当你尝试编译这段代码时，编译器会立刻报错，可能的消息是： 'doWrok' marked 'override' but does not override any base class method. （’doWrok’ 被标记为 override，但它没有重写任何基类方法。）

编译器强制你修正错误，直到函数的签名与基类中的某个虚函数完全匹配为止。

正确的写法：

class Base {
public:
    virtual void doWork() const { /* ... */ }
};

class Derived : public Base {
public:
    // 完全匹配，并且用 override 明确意图
    virtual void doWork() const override { /* ... */ }
};

final关键字

与 override 相关的还有一个 C++11 关键字是 final。它有两个用途：

1. 用于函数：阻止派生类进一步重写。

   class A {
   public:
       virtual void foo();
   };
   class B : public A {
   public:
       void foo() final override; // B::foo 重写了 A::foo，并且是最终版本
   };
   class C : public B {
   public:
       // void foo() override; // 编译错误！B::foo 是 final 的
   };
   

2. 用于类：阻止类被继承。

   class Sealed final { /* ... */ };
   // class DerivedFromSealed : public Sealed {}; // 编译错误！Sealed 不能被继承
   

总结：

• override 的好处：
  1. 提高代码可读性：读者一眼就能看出这个函数是用来重写的。
  2. 强制编译器检查：将隐蔽的运行时多态错误，转变为清晰的编译时错误。
  3. 提升代码健壮性：防止因基类变更而导致的意外行为。
• 最佳实践：养成习惯，只要你打算重写一个虚函数，就在函数声明的末尾加上 override。这是现代 C++ 编程中一个简单却极其有效的防御性编程技巧。

item13：优先考虑const iterator而非iterator

尽可能地使用 const_iterator 进行只读操作，只有当你确实需要修改容器中的元素时，才使用 iterator。

这背后的原则是“最小权限原则” (Principle of Least Privilege)：只授予代码完成其任务所必需的最小权限。如果你的代码只需要读取数据，就不应该给予它写入数据的能力。

iterator 和 const_iterator 的区别

#include <iostream>
#include <vector>
#include <algorithm>

int main() {
    std::vector<int> v = {10, 20, 30};

    // --- 使用 iterator (可读可写) ---
    std::vector<int>::iterator it = v.begin();
    std::cout << "Original value: " << *it << std::endl; // 读取: OK
    *it = 99; // 写入/修改: OK!
    std::cout << "Modified value: " << *it << std::endl; // v 现在是 {99, 20, 30}

    // --- 使用 const_iterator (只读) ---
    std::vector<int>::const_iterator cit = v.cbegin(); // 使用 cbegin() 获取 const_iterator
    std::cout << "Value via const_iterator: " << *cit << std::endl; // 读取: OK

    // *cit = 100; // 写入/修改: 编译错误！
    // 编译器会报错，类似: "assignment of read-only location"
    
    return 0;
}

注意！const_iterator it不能用const auto it或者auto const it来替代!

const auto it或者auto const it是相同的意思，表达的是it本身(地址)是一个常量，而它指向的内容并不是常量。

而const_iterator it表达的意思是：it指向的内容是一个常量，不允许修改。it本身可以修改

为什么要优先选择 const_iterator？

考虑一个函数，它的功能是打印 vector 的内容：

// 这个函数承诺不会修改传入的 'container'
void print_elements(const std::vector<int>& container) {
    // 错误的做法：
    // std::vector<int>::iterator it = container.begin(); // 编译错误！
    // 你不能从一个 const 容器中获取一个非 const 的 iterator。
    // 因为如果允许了，你就可以通过 it 修改 const 容器了，这违背了 const 承诺。

    // 正确的做法：
    std::vector<int>::const_iterator cit = container.cbegin(); // OK
    // 或者更现代的写法：
    // auto cit = container.cbegin(); // auto 推导出的类型是 const_iterator
    
    for (; cit != container.cend(); ++cit) {
        std::cout << *cit << " ";
    }
    std::cout << std::endl;
}

通过使用 const_iterator，你的函数可以同时接受 const 和非 const 的容器，使其适用性更广。如果你用了 iterator，这个函数就无法处理 const 容器了。

当你的意图只是遍历和读取时，使用 const_iterator 就像上了一道保险。编译器会帮你检查，确保你不会在代码的某个角落意外地修改了容器中的值。这使得代码的意图更加清晰：看到 const_iterator，任何阅读代码的人都会立刻明白这里的操作是只读的。

在 C++11 之前，const_iterator 的类型名写起来很长，有点麻烦。但 C++11 引入了 cbegin() 和 cend() 成员函数，以及 auto 关键字，极大地简化了这一过程。

• container.begin(): 如果 container 是非 const 的，返回 iterator；如果是 const 的，返回 const_iterator。
• container.cbegin(): 无论 container 是否是 const，永远返回 const_iterator。

std::vector<int> numbers = {1, 2, 3};

// 当你只需要读取时，明确使用 cbegin
for (auto it = numbers.cbegin(); it != numbers.cend(); ++it) {
    std::cout << *it; // 读取 OK
    // *it = 5; // 编译错误，正如你所期望的
}

// 当你需要修改时，才使用 begin
for (auto it = numbers.begin(); it != numbers.end(); ++it) {
    *it *= 2; // 修改 OK
}

cbegin() 是向编译器和代码读者传达“我在这里是只读”意图的最清晰方式。

一个常见的混淆点：const_iterator vs. const iterator

这两者是完全不同的东西，就像 const T* 和 T* const 的区别一样。

• const_iterator: 一个指向常量的迭代器。你不能修改它指向的元素，但可以移动迭代器本身（例如 it++）。

std::vector<int>::const_iterator cit = v.cbegin();
// *cit = 10;   // 错误！不能修改所指元素
++cit;       // 正确！可以移动迭代器

• const iterator: 一个常量迭代器。迭代器本身不能被移动去指向别处，但你可以修改它当前指向的元素（如果它是一个非 const 的 iterator 的话）。

std::vector<int> v = {1, 2};
const std::vector<int>::iterator it = v.begin();
*it = 10;    // 正确！可以修改所指元素
// ++it;        // 错误！不能移动迭代器本身

在实践中，const iterator 很少使用，我们通常关心的是 const_iterator。

记住这个简单的规则：默认使用 cbegin()，除非你真的需要修改元素

item14：如果函数不抛出异常请使用noexcept

什么是 noexcept？

想象你在进行一项名为“程序运行”的实验。 以前（C++98 时代），函数就像是一个随时可能爆炸的实验室。编译器为了安全，不得不时刻准备着“如果炸了怎么办”，这需要记录很多额外的信息（unwindable state），就像我要时刻准备着拿灭火器一样。

而 noexcept 就像是你跟编译器签的一份“绝对安全协议”。 你告诉编译器：“放心吧，这个函数绝对不会爆炸（抛异常）。” 既然你都敢签协议了，编译器就可以把手里的灭火器扔掉，甚至把防火门都拆了——这就意味着生成的机器码更少，运行速度更快！

在 C++11 里，我们引入了移动语义（Move Semantics），也就是 Item 23 讲的那个。 假设你有一个装满重物的箱子（std::vector），现在箱子满了，你需要换个大仓库。

• 如果没有 noexcept（保守派）： std::vector 会非常怂。它在搬家的时候，因为怕搬运过程中出事（抛异常），它不敢直接把旧仓库的东西“瞬移”过去，而是会选择把每个东西都复制一遍放到新仓库，然后再销毁旧的。

  后果： 慢！极其慢！就像是你明明可以直接把实验器材抱走，却非要重新买一套一模一样的。

• 如果你加了 noexcept（激进派）： std::vector 一看你的移动构造函数上有 noexcept 签名，它就放心了：“既然你也说了不会出事，那我就不复制了，直接移动！”

  后果： 效率爆炸提升！特别是在容器扩容的时候，原本的“全部拷贝”变成了“全部移动”。

例：std::vector的扩容机制

当 std::vector 的容量（capacity）不够用，需要 push_back 新元素时，它会开辟一块更大的内存，然后把旧内存里的元素迁移过去。

关键点来了： 它是“搬过去”（Move）还是“抄过去”（Copy）？

C++ 标准库为了保证强异常安全性（Strong Exception Guarantee），有一个很保守的策略：

如果移动构造函数可能抛出异常（没加 noexcept），为了防止搬运搬到一半突然炸了导致数据丢失，vector 会选择放弃移动，直接复制。

只有当你明确承诺 noexcept，它才敢大胆地使用 Move。

class SlowObject {
public:
    SlowObject() {}

    // 复制构造函数
    SlowObject(const SlowObject&) {
        std::cout << "Copying SlowObject (好累...)\n";
    }

    // 移动构造函数（注意：这里没加 noexcept！）
    // 即使你写了移动逻辑，vector 也不敢用！
    SlowObject(SlowObject&&) {
        std::cout << "Moving SlowObject (瞬移!)\n";
    }
};


class FastObject {
public:
    FastObject() {}

    // 复制构造函数
    FastObject(const FastObject&) {
        std::cout << "Copying FastObject (好累...)\n";
    }

    // 移动构造函数（加了 noexcept！）
    // 这是一个“不会失败的承诺”
    FastObject(FastObject&&) noexcept {
        std::cout << "Moving FastObject (瞬移!)\n";
    }
};

int main() {
    std::cout << "--- 测试 SlowObject (没加 noexcept) ---\n";
    std::vector<SlowObject> vSlow;
    vSlow.reserve(2); 
    vSlow.emplace_back(); // 放第1个
    vSlow.emplace_back(); // 放第2个 (满了)
    
    // 关键时刻：再放第3个，触发扩容！
    // 旧的两个元素需要迁移到新内存
    std::cout << "Triggering resize:\n";
    vSlow.emplace_back(); 

    std::cout << "\n--- 测试 FastObject (加了 noexcept) ---\n";
    std::vector<FastObject> vFast;
    vFast.reserve(2);
    vFast.emplace_back();
    vFast.emplace_back();
    
    // 关键时刻：触发扩容
    std::cout << "Triggering resize:\n";
    vFast.emplace_back(); 
}

结果:

--- 测试 SlowObject (没加 noexcept) ---
Triggering resize:
Copying SlowObject (好累...)
Copying SlowObject (好累...)

--- 测试 FastObject (加了 noexcept) ---
Triggering resize:
Moving FastObject (瞬移!)
Moving FastObject (瞬移!)

为移动构造函数、移动赋值运算符和 swap 函数加上 noexcept，对于使用标准库容器的性能来说，是至关重要的。

noexcept 的用法和规则

• noexcept 作为修饰符:

  void f() noexcept; // f 承诺不抛出异常
  

• noexcept 作为条件运算符 (noexcept(expression)): 这是一个编译期的运算符，它返回一个 bool 类型的 constexpr 值。如果 expression 被编译器分析为不会抛出任何异常，它就返回 true，否则返回 false。

  int i;
  noexcept(i++);          // 返回 true，因为 int 的自增不抛异常
  noexcept(std::string()); // 返回 true，默认构造函数不抛异常
  noexcept(std::vector<int>().push_back(1)); // 返回 false，push_back 可能会因内存分配失败而抛异常
  

• 条件 noexcept (noexcept(...)): 这是 noexcept 最强大的用法，尤其是在模板编程中。你可以让一个函数的 noexcept 状态依赖于它内部调用的操作。

  template<typename T, size_t N>
  void swap(T (&a)[N], T (&b)[N]) noexcept(noexcept(std::swap(*a, *b))) {
      // 这个 swap 函数是 noexcept 的，当且仅当
      // 对数组内单个元素调用 std::swap 是 noexcept 的。
      // ...
  }
  

  告诉编译器：“如果std::swap(*a, *b)不抛异常，那我也就不抛异常”。

如果承诺了noexcept却抛出了异常

void doDangerousThing() noexcept { // 承诺不抛异常
    throw std::runtime_error("Ha! I lied!"); // 实际上抛了
}

int main() {
    try {
        doDangerousThing();
    } catch (...) {
        // 不能捕获异常！
        std::cout << "Caught it!\n"; 
    }
    return 0;
}

程序直接 Crash，输出类似于 terminate called after throwing an instance of...。 那个 catch 块永远不会执行。 编译器看到 noexcept 后，可能根本就没有生成用于捕获异常的堆栈展开（Stack Unwinding）代码。一旦出事，唯一的路就是 std::terminate

item15：尽可能的使用constexpr

constexpr对象

从概念上来说，constexpr表明一个值不仅仅是常量，还是编译期可知的。

如果你能在编译阶段就把结果算出来，意味着什么？

1. 运行时耗时为 0：程序跑起来的时候，结果已经在那了，根本不用算。
2. 更广泛的用途：很多地方只能填“编译期常量”，比如数组的大小、模板的参数、switch 语句的 case 标签。普通变量根本进不去，但 constexpr 可以！

int sz = 10; // 普通变量
// sz 的值在编译期是未知的（虽然这里看着像10，但编译器认为它可能会变）

const auto constSize = sz; // 正确，constSize 是只读的
// std::array<int, constSize> data; // ❌ 错误！编译器报错！
// 因为编译器说：“运行的时候我才知道 constSize 是几，现在我怎么给你开数组？”

constexpr auto exprSize = 10; // 正确，编译期已知
std::array<int, exprSize> data; // ✅ 完美！编译器很高兴

constexpr函数

constexpr 函数不仅能用于编译期计算，它还有一种“自适应”的能力。

• 当你喂给它编译期常量时： 它会在编译期算出结果，变成一个常量。
• 当你喂给它运行时变量时： 它就退化成一个普通的函数，在运行时计算。

// constexpr 函数
// 在 C++11 中限制很多，通常只能写一行 return
// 但在 C++14 及以后，你可以写循环、判断，随你便
constexpr int pow(int base, int exp) noexcept {
    auto result = 1;
    for (int i = 0; i < exp; ++i) result *= base;
    return result;
}

int main() {
    // 场景 A：全部是编译期常量
    constexpr auto numCond = 5;
    // 编译器在编译阶段就算出了 2^5 = 32
    // 这一行代码在生成的二进制文件里，直接就是 std::array<int, 32>
    std::array<int, pow(2, numCond)> results; 

    // 场景 B：参数包含运行时变量
    int x = 10; // 运行时才知道
    int y = 3;
    // 没问题！它会自动降级为普通函数调用，在运行时计算 10^3
    auto val = pow(x, y); 
    
    return 0;
}

如果你设计一个类，把它的构造函数和成员函数都标记为 constexpr，那么这个类的对象甚至可以在编译期被创建、操作！

class Point {
public:
    // 构造函数是 constexpr
    constexpr Point(double xVal = 0, double yVal = 0) noexcept
        : x(xVal), y(yVal) {}

    // getter 也是 constexpr
    constexpr double xValue() const noexcept { return x; }
    constexpr double yValue() const noexcept { return y; }

    // C++14 开始，setter 也可以是 constexpr（修改局部对象）
    constexpr void setX(double newX) noexcept { x = newX; }

private:
    double x, y;
};

// 一个计算中点的 constexpr 函数
constexpr Point midpoint(const Point& p1, const Point& p2) noexcept {
    return { (p1.xValue() + p2.xValue()) / 2, 
             (p1.yValue() + p2.yValue()) / 2 };
}

int main() {
    constexpr Point p1(9.4, 27.7);
    constexpr Point p2(28.8, 5.3);

    // 这一步计算，在编译生成 exe 之前就已经完成了！
    // 编译器直接算出了中点，并把它“烧录”进了程序里。
    constexpr auto mid = midpoint(p1, p2);

    // 甚至可以用这个计算结果去定义别的常量
    static_assert(mid.xValue() == 19.1, "Calculation error!"); 
}

这有什么用？ 这意味着初始化的开销完全被消除了。对于嵌入式系统或者对性能要求极高的场景，这简直就是魔法

item16：让const成员函数线程安全

这是一个在多线程编程中极其重要的概念。它揭示了 C++ const 关键字在并发环境下的一个微妙但关键的含义：从调用者的角度来看，const 成员函数不仅意味着不改变对象的可观察状态，还隐含着一个承诺——它可以被多个线程同时安全地调用。

在单线程世界里，const 成员函数的意义很明确：它是一个“只读”操作，不会修改对象的任何成员变量。编译器会强制执行这一点（这被称为 bitwise constness，位级常量性）。

但是，有时候为了实现某些优化（如缓存、懒加载），我们希望 const 函数能够修改一些内部的、对外部不可见的成员。这时我们会使用 mutable 关键字来突破编译器的限制。这被称为 logical constness（逻辑常量性），即对象对外的逻辑状态没变，但内部的物理表示变了。

在C++中mutable关键字是为了突破const关键字的限制，被mutable关键字修饰的成员变量永远处于可变的状态，即使是在被const修饰的成员函数中。

问题来了：当多个线程同时调用同一个对象的同一个 const 成员函数时，如果这个函数内部正在修改一个 mutable 成员，就会发生数据竞争 (data race)，从而导致未定义行为 (Undefined Behavior)。

Item 16 的核心论点是：你必须确保你的 const 成员函数是线程安全的。 如果它内部确实需要修改数据，那么这些修改必须被同步（例如，使用互斥锁 std::mutex 或原子操作 std::atomic）。

多线程竞争

例：

#include <vector>

class Polynomial {
public:
    std::vector<double> getRoots() const {
        if (!rootsAreValid) { // 检查缓存是否有效
            // ... 执行昂贵的根计算 ...
            rootVals = { /* 计算出的根 */ }; // 1. 写入缓存
            rootsAreValid = true;             // 2. 标记缓存有效
        }
        return rootVals;
    }

private:
    mutable bool rootsAreValid{false}; // 缓存是否有效的标志
    mutable std::vector<double> rootVals; // 缓存的根
    // ... 其他代表多项式的成员
};

• getRoots() 被声明为 const，因为它从逻辑上不改变多项式本身（系数等）。
• 为了能实现缓存，rootsAreValid 和 rootVals 必须声明为 mutable，这样才能在 const 函数内修改它们。

在单线程中，这完美工作。但在多线程中，这是灾难性的：

数据竞争场景：

1. 线程 A 调用 poly.getRoots()。它检查 rootsAreValid，发现是 false，于是进入 if 块，准备开始计算。
2. 线程切换！
3. 线程 B 也调用 poly.getRoots()。它也检查 rootsAreValid，发现它仍然是 false（因为线程 A 还没来得及修改它），于是也进入 if 块。
4. 现在，两个线程都在执行昂贵的计算，这是重复劳动。
5. 更糟糕的是，线程 A 和线程 B 将会无保护地写入 rootVals 和 rootsAreValid。这是一个典型的数据竞争。哪个线程的写入会“获胜”是未知的，rootVals 的最终内容可能是损坏的，程序可能会崩溃。

如何实现线程安全

为了修复这个问题，我们必须对 mutable 成员的访问进行同步。

使用 std::mutex

这是最通用、最常见的解决方案。我们在类中添加一个 mutable std::mutex，并在 const 函数内部使用它来保护“临界区”（critical section），也就是访问共享数据的代码块。

#include <mutex>

class Polynomial {
public:
    std::vector<double> getRoots() const {
        // 使用 std::lock_guard 实现 RAII 式的加锁/解锁
        std::lock_guard<std::mutex> guard(m); // 构造时加锁，析构时自动解锁

        // --- 进入临界区 ---
        if (!rootsAreValid) {
            // ... 执行昂贵的根计算 ...
            rootVals = { /* ... */ };
            rootsAreValid = true;
        }
        return rootVals;
        // --- 离开临界区 (guard 析构，锁被释放) ---
    }

private:
    mutable std::mutex m; // 必须是 mutable
    mutable bool rootsAreValid{false};
    mutable std::vector<double> rootVals;
};

使用 std::atomic

对于简单的、可以被单条CPU指令修改的变量（如标志位、计数器、指针），使用 std::atomic 通常比 std::mutex 更轻量、性能更好。

让我们用一个更简单的例子来说明。假设我们想统计一个 const 函数被调用了多少次。

不安全的版本

class Counter {
public:
    int getCallCount() const {
        ++callCount; // 数据竞争！++不是原子操作
        return callCount;
    }
private:
    mutable int callCount{0};
};

使用 std::atomic 的安全版本：

#include <atomic>

class Counter {
public:
    int getCallCount() const noexcept {
        // fetch_add 是原子操作，线程安全
        return callCount.fetch_add(1, std::memory_order_relaxed) + 1;
    }
private:
    mutable std::atomic<int> callCount{0};
};

• mutable std::atomic<int>: 我们将计数器声明为 std::atomic<int>。

• callCount.fetch_add(1): 这是一个原子操作，它会读取当前值，然后给它加 1，整个过程不会被其他线程中断。这比使用互斥锁的开销要小得多

• std::memory_order_relaxed：“最弱的指令重排顺序，你随便优化！”。它只保证这个原子操作本身是原子的（即 fetch_add 不会被撕裂）。但是，它不提供任何关于其他内存操作的排序保证。编译器和 CPU 可以最大限度地对它周围的代码进行重排。

总结：

1. const 意味着线程安全：为你的类的用户着想，你应该假设他们会在多线程环境中调用对象的 const 成员函数。因此，你有责任确保这些调用是安全的。
2. 识别共享数据：检查你的 const 成员函数，找出所有被修改的 mutable 成员变量。这些就是需要被保护的共享数据。
3. 选择正确的同步机制：
   • 如果只涉及对单个变量的简单操作，优先使用 std::atomic，因为它性能更好。
   • 如果需要保护一个代码块，或者修改多个相互关联的变量，使用 std::mutex（通常配合 std::lock_guard 或 std::scoped_lock）。
4. mutable 是同步机制的朋友：不要忘记将你的 std::mutex 或 std::atomic 成员也声明为 mutable。

item17：理解特殊成员函数的生成

什么是特殊成员函数？

C++ 中有六个“特殊成员函数”，编译器可能会在需要时为你隐式地声明和定义它们：

1. 默认构造函数 (Default Constructor): Widget();
2. 析构函数 (Destructor): ~Widget();
3. 拷贝构造函数 (Copy Constructor): Widget(const Widget&);
4. 拷贝赋值运算符 (Copy Assignment Operator): Widget& operator=(const Widget&);
5. 移动构造函数 (Move Constructor) (C++11): Widget(Widget&&);
6. 移动赋值运算符 (Move Assignment Operator) (C++11): Widget& operator=(Widget&&);

Item 17 的核心就是讲解这六个函数之间“牵一发而动全身”的相互影响关系。

C++11之前

在 C++11 之前，规则相对简单，被称为“三法则”。 它指出：如果你需要显式地声明析构函数、拷贝构造函数、或拷贝赋值运算符中的任何一个，那么你几乎肯定需要同时声明所有这三个。

为什么？ 因为显式声明其中之一，通常意味着你的类正在手动管理某种资源（如裸指针、文件句柄、网络套接接字等）。

• 显式析构函数：意味着你需要在对象销毁时释放资源（delete ptr;）。
• 如果这时你依赖编译器生成的默认拷贝构造/赋值，它们只会执行浅拷贝 (shallow copy)，即简单地复制指针的值。这会导致两个对象指向同一块内存，当其中一个对象被析构时，它会释放该内存，留下另一个对象的指针悬空。当第二个对象也被析构时，就会发生二次释放 (double free)，导致程序崩溃。
• 因此，你必须提供自定义的拷贝操作来实现深拷贝 (deep copy)，为新对象分配新的资源。

这就是三法则的精髓：手动管理资源需要一套完整的“构造-析构-拷贝”逻辑。

c++11之后

C++11 引入了移动语义，增加了两个新的特殊成员函数（移动构造和移动赋值）。更重要的是，它改变了编译器生成这些函数的规则，使其变得更加智能，也更加复杂。

核心原则：编译器认为，如果你显式声明了任何一个“资源管理”相关的函数（拷贝、移动、析构），这表明你对资源管理有特殊的意图，编译器默认生成的行为可能是不安全的。因此，它会变得“保守”，并禁用某些函数的自动生成。

规则 1：用户声明“拷贝操作”会阻止“移动操作”的生成

如果你显式声明了拷贝构造函数或拷贝赋值运算符中的任何一个：

• 编译器不会为你自动生成移动构造函数和移动赋值运算符。

理由：你已经定义了如何拷贝你的对象，这表明简单的成员逐一移动可能是不正确的。编译器不知道如何正确地“移动”你的资源，所以它选择不做，让你自己来定义。如果没有定义移动操作，那么需要移动的地方将会退回到使用拷贝操作。

规则 2：用户声明“移动操作”会阻止“拷贝操作”的生成

如果你显式声明了移动构造函数或移动赋值运算符中的任何一个：

• 编译器不会为你自动生成拷贝构造函数和拷贝赋值运算符。

理由：你已经告诉编译器“移动”和“拷贝”是不同的。这通常意味着你的类是“只移类型”（move-only），比如 std::unique_ptr。既然你已经提供了移动的特殊逻辑，那么默认的成员逐一拷贝很可能是错误的，所以编译器禁用它们。如果你还想让你的类可拷贝，你必须显式地去 = default 或自己实现它们。

规则 3：用户声明“拷贝/移动/析构”三者之一，会阻止“移动操作”的生成

如果你显式声明了以下三者中的任何一个：

• 拷贝构造函数
• 拷贝赋值运算符
• 析构函数

那么：

• 编译器不会为你自动生成移动构造函数和移动赋值运算符。

理由：这与“三法则”的逻辑一脉相承。显式声明析构函数强烈地暗示你在手动管理资源。如果一个类手动管理资源，那么编译器生成的成员逐一移动（它只会移动指针，而不会将源指针置空）几乎肯定是错误的，会导致资源的二次释放。因此，为了安全，编译器干脆不生成移动操作。同理，声明了拷贝操作也暗示了资源管理，所以也会禁用移动操作的生成。

基于上述规则，现代 C++ 的实践演变成了两个新的指导方针：

The Rule of Five (五法则)

这扩展了三法则：如果你需要显式地声明析构函数、拷贝构造、拷贝赋值、移动构造、移动赋值中的任何一个，那么你就应该审视所有这五个函数，并根据需要显式地定义、= default 或 = delete 它们。

class Widget {
public:
    // ... constructor that acquires resource ...

    // 1. Destructor
    ~Widget() { delete data; }

    // 2. Copy Constructor (deep copy)
    Widget(const Widget& other) : data(new int(*other.data)) {}

    // 3. Copy Assignment (copy-and-swap idiom)
    Widget& operator=(const Widget& other) {
        // ... self-assignment check & deep copy ...
        return *this;
    }

    // 因为我们声明了析构和拷贝操作，移动操作不会被自动生成。
    // 我们必须自己提供它们！
    
    // 4. Move Constructor
    Widget(Widget&& other) noexcept : data(other.data) {
        other.data = nullptr; // Crucial: leave source in a valid state
    }

    // 5. Move Assignment
    Widget& operator=(Widget&& other) noexcept {
        // ... self-assignment check ...
        delete data;
        data = other.data;
        other.data = nullptr;
        return *this;
    }

private:
    int* data;
};

The Rule of Zero (零法则) - 这是最佳实践！

这是现代 C++ 最推崇的理念。它指出：你应该尽量设计你的类，使得你根本不需要声明任何一个特殊成员函数。

如何做到？ 通过组合。不要在你的类中使用裸指针、裸资源句柄。而是使用那些已经正确实现了五法则的资源管理类作为你的成员变量。例如：

• 用 std::unique_ptr 或 std::shared_ptr 来管理动态分配的内存。
• 用 std::string 来管理动态字符串。
• 用 std::vector 来管理动态数组。

item18：对于独占资源使用std::unique_ptr

std::unique_ptr 是一个模板，它管理一个动态分配的对象。它的行为和裸指针非常相似，但提供了关键的自动内存管理。

关键特性:

• 独占所有权：在任何时刻，只有一个 unique_ptr 可以指向一个给定的对象。
• 自动清理：当 unique_ptr 被销毁时（例如，离开作用域），它会自动 delete 它所管理的对象。这利用了 RAII 机制，从根本上防止了内存泄漏。
• 轻量级：它的大小与裸指针完全相同。对它进行解引用 (* 或 ->) 的速度也和裸指针一样快。它是一个真正的“零成本抽象”。

为什么unique_ptr不能拷贝？

因为如果你能拷贝一个std::unique_ptr，你会得到指向相同内容的两个std::unique_ptr，每个都认为自己拥有（并且应当最后销毁）资源，销毁时就会出现重复销毁。因此，std::unique_ptr是一种只可移动类型（move-only type）。

std::unique_ptr作为工厂函数的返回值

这是 unique_ptr 最常见和最强大的用途之一。在 C++98 中，工厂函数通常返回一个裸指针，这就把内存管理的责任抛给了调用者。调用者很容易忘记 delete，从而导致内存泄漏。

旧的、危险的方式 (返回裸指针):

class Investment { /* ... */ };

// 工厂函数
Investment* makeInvestment() {
    // ... 一些逻辑 ...
    return new Investment(); // 调用者必须记得 delete！
}

// 调用代码
void process() {
    Investment* pInv = makeInvestment();
    // ... 使用 pInv ...
    // 如果在这里提前 return 或抛出异常，pInv 就泄露了！
    delete pInv; // 容易忘记，且非异常安全
}

现代的、安全的方式 (返回 std::unique_ptr):

#include <memory>

class Investment { /* ... */ };

// 工厂函数返回 unique_ptr
std::unique_ptr<Investment> makeInvestment() {
    // ...
    return std::make_unique<Investment>();
}

// 调用代码
void process() {
    auto pInv = makeInvestment(); // pInv 是 std::unique_ptr<Investment>
    // ... 使用 pInv ...
    // 不管函数如何退出（正常返回、提前 return、抛出异常），
    // pInv 都会在离开作用域时被自动销毁，其管理的 Investment 对象也会被 delete。
    // 绝对不会有内存泄漏。
}

这种模式清晰地传达了所有权的转移：makeInvestment 函数创建了资源，并将它的所有权完全转移给了调用者 process

自定义删除器

unique_ptr 的强大之处在于，它不仅仅能管理通过 new 分配的内存。通过自定义删除器 (custom deleter)，它可以管理任何需要成对“获取/释放”操作的资源。

自定义删除器是一个函数或函数对象，它告诉 unique_ptr 在销毁时应该执行什么操作，而不是简单地调用 delete。

#include <cstdio>
#include <memory>

// 自定义删除器，用于关闭文件
auto fileCloser = [](FILE* fp) {
    if (fp) {
        fclose(fp);
        std::cout << "File closed by custom deleter." << std::endl;
    }
};

// 工厂函数，打开一个文件并返回一个 unique_ptr
std::unique_ptr<FILE, decltype(fileCloser)> makeFile(const char* filename, const char* mode) {
    FILE* fp = fopen(filename, mode);
    // 将裸指针和自定义删除器包装进 unique_ptr
    return std::unique_ptr<FILE, decltype(fileCloser)>(fp, fileCloser);
}

void useFile() {
    auto pFile = makeFile("my_log.txt", "w");
    if (pFile) {
        fputs("Hello, RAII file management!", pFile.get());
    }
    // useFile 函数结束时，pFile 会被销毁，
    // 从而自动调用 fileCloser 来关闭文件。
}

详解std::unique_ptr<FILE, decltype(fileCloser)>

我们通常见到的 std::unique_ptr 是这样的：std::unique_ptr<MyClass>。这其实是一个简写。

std::unique_ptr 的完整模板声明看起来更像这样：

template<
    class T,
    class Deleter = std::default_delete<T>
> class unique_ptr;

• T: 这是 unique_ptr 所管理的对象的类型。所以 unique_ptr 内部实际上持有一个 T* 类型的裸指针。
• Deleter: 这是删除器的类型。它是一个函数对象（或函数指针）的类型，unique_ptr 在自己被销毁时，会调用这个 Deleter 来释放资源。它的默认值 std::default_delete<T> 只是简单地对内部指针调用 delete。

当我们想要管理的资源不是通过 new 创建、不能用 delete 释放时，我们就需要提供自己的 Deleter。

在这段代码std::unique_ptr<FILE, decltype(fileCloser)>中，这里的 T 是 FILE。

• FILE 是 C 语言标准库（<cstdio>）中用于文件操作的结构体。
• 我们从不直接创建 FILE 对象，而是通过 fopen() 函数获取一个指向它的指针，即 FILE*。
• FILE* 类型的资源不能用 delete 来释放，而必须使用配对的 fclose() 函数来关闭。

所以，std::unique_ptr<FILE, ...> 的意思是：“我是一个 unique_ptr，我内部持有一个 FILE* 类型的指针。” 因为不能用 delete，所以我们必须提供第二个模板参数来告诉它正确的清理方法

问题：为什么make_file()函数的返回值不用make_unique?

std::make_unique 被设计用来处理一种、且只有一种情况：在堆上分配内存并构造一个新对象。 它无法处理我们这里的场景，即接管一个已经存在的、由其他方式创建的资源，也无法附加一个自定义删除器。

std::make_unique 的设计中没有提供任何接口来让你：

• 传入一个已经存在的裸指针。
• 传入一个自定义的删除器对象。

当你需要 new 一个对象时，请使用 std::make_unique。 这是现代 C++ 的标准实践。

当你需要管理一个不是由 new 创建的资源时（比如 C API 返回的句柄、指针），请直接使用 std::unique_ptr 的构造函数，并为其提供一个自定义删除器。

unique_ptr和shared_ptr的关系

Item 18 强调 unique_ptr 是默认选择。那么什么时候才需要 shared_ptr 呢？

• std::unique_ptr 代表 独占所有权。它很小，很快，并且所有权模型非常清晰。
• std::shared_ptr 代表 共享所有权。它用于“一个资源可能被多个所有者共同拥有，直到最后一个所有者消失时才被释放”的场景。它更大（通常是裸指针的两倍大小），更慢（需要原子地增减引用计数），所有权模型也更复杂（可能导致循环引用）。

最佳实践： 你应该默认使用 std::unique_ptr。只有当你发现你确实需要共享所有权时，才考虑升级到 std::shared_ptr。

一个常见的模式是：工厂函数返回 std::unique_ptr，让调用者先获得独占所有权。如果调用者后续发现需要将这个资源共享出去，它可以轻松地将 unique_ptr 转换为 shared_ptr。

auto pInvestment = makeInvestment(); // 返回 unique_ptr

// ... 一些只由我使用的代码 ...

// 现在，我需要和别人共享这个 Investment 对象了
std::shared_ptr<Investment> spInvestment = std::move(pInvestment);
// 所有权从 unique_ptr 转移给了 shared_ptr
// pInvestment 现在为空

item19：对于共享资源使用std::shared_ptr

std::shared_ptr 实现的是共享所有权 (shared ownership) 的语义。这意味着，多个 shared_ptr 实例可以同时拥有并管理同一个对象。这个被管理的对象只有在最后一个指向它的 shared_ptr 被销毁或重置时，才会被自动删除。

这解决了 unique_ptr 无法处理的一类问题：当一个资源（如一个大的数据对象、一个服务实例等）的生命周期不是由单一的代码块或对象决定，而是由多个独立的、生命周期各不相同的“客户端”共同决定时，shared_ptr 就是正确的工具。

引用计数

shared_ptr 的魔法在于引用计数 (reference counting)。

每个由 shared_ptr 管理的对象，都关联着一个控制块 (control block)。这个控制块是一个独立于被管理对象、在堆上分配的小块内存，它至少包含两样东西：

1. 强引用计数 (Strong Reference Count)：记录有多少个 shared_ptr 正指向这个对象。这是决定对象生命周期的关键。
2. 弱引用计数 (Weak Reference Count)：记录有多少个 std::weak_ptr (我们稍后会讲) 指向这个对象。

shared_ptr 的生命周期管理规则：

• 当一个新的 shared_ptr 通过拷贝构造或拷贝赋值指向一个对象时，强引用计数 +1。
• 当一个 shared_ptr 被销毁（离开作用域）、重置或被赋予其他指针时，强引用计数 -1。
• 当强引用计数降为 0 时，shared_ptr 会自动 delete 它所管理的对象。
• 当弱引用计数也降为 0 时（意味着也没有 weak_ptr 指向它了），控制块本身才会被释放。

如何创建 std::shared_ptr

与 unique_ptr 类似，创建 shared_ptr 的唯一推荐方式是使用 C++11 的 std::make_shared。

#include <memory>

class Widget { /* ... */ };

// 创建一个指向 Widget 对象的 shared_ptr
auto spw = std::make_shared<Widget>();

为什么必须用 std::make_shared？

除了和 make_unique 一样能提供简洁性和异常安全之外，make_shared 还有一个极其重要的性能优势：

• 传统的创建方式：std::shared_ptr<Widget> spw(new Widget()); 这会导致两次内存分配：
  1. new Widget(): 为 Widget 对象本身分配内存。
  2. shared_ptr 的构造函数内部：为控制块分配内存。 这两次分配在内存中可能是分离的，降低了缓存效率，并且增加了分配开销。
• 使用 std::make_shared：auto spw = std::make_shared<Widget>(); make_shared 会执行一次单独的、更大的内存分配，这块内存足以同时容纳 Widget 对象和控制块。 优点：
  1. 性能：将两次内存分配合并为一次，显著提高了效率。
  2. 内存局部性 (Memory Locality)：对象和它的控制块在内存中是相邻的，这有助于提高 CPU 缓存的命中率。

结论：除非有极特殊的理由（比如要接管一个已经存在的裸指针），否则永远使用 std::make_shared 来创建 shared_ptr。

shared_ptr 的性能和内存开销

shared_ptr 并非免费的午餐。相比 unique_ptr，它有额外的开销：

1. 大小：一个 shared_ptr 对象的大小是裸指针的两倍。一个指针指向被管理的对象，另一个指针指向控制块。
2. 引用计数是原子的：为了在多线程环境下安全地拷贝和销毁 shared_ptr，引用计数的增减操作必须是原子操作 (atomic operations)。原子操作通常比普通的整数操作要慢。
3. 控制块的分配开销：如上所述，控制块需要额外的内存分配（除非使用 make_shared）。

因此，Item 19 强调 shared_ptr 是用于共享所有权的，这意味着你不应该因为它看起来“更强大”或“更安全”就在所有地方都使用它。如果一个资源的生命周期是清晰的、线性的，unique_ptr 是一个性能好得多的选择。

举例

想象一下，一个家庭里有多位成员，他们共同拥有一只宠物。这只宠物只有在所有家庭成员都搬走（或者不再关心它）之后，才会被送到宠物收容所。

• 宠物 (Pet) 就是我们用 shared_ptr 管理的资源。
• 家庭成员 (Family Member) 就是那些 shared_ptr 的实例

#include <iostream>
#include <string>
#include <memory>

// 代表我们的共享资源
class Pet {
public:
    Pet(std::string name) : name_(std::move(name)) {
        std::cout << "Pet '" << name_ << "' has been adopted!\n";
    }

    ~Pet() {
        std::cout << "Pet '" << name_ << "' has been sent to the shelter.\n";
    }

    void greet() const {
        std::cout << name_ << " says Woof!\n";
    }

private:
    std::string name_;
};


int main() {
    // 1. 爸爸领养了一只宠物。
    //    我们使用 std::make_shared 来创建一个 Pet 对象，并用 shared_ptr 管理它。
    std::shared_ptr<Pet> dads_ptr = std::make_shared<Pet>("Rex");
    std::cout << "Rex's reference count: " << dads_ptr.use_count() << "\n"; // 引用计数为 1

    dads_ptr->greet();

    std::cout << "\n";

    // 2. 妈妈也把这只宠物当作自己的。
    //    我们通过拷贝 dads_ptr 来创建一个新的 shared_ptr。
    std::shared_ptr<Pet> moms_ptr = dads_ptr;
    std::cout << "Rex's reference count: " << dads_ptr.use_count() << "\n"; // 引用计数变为 2
    
    moms_ptr->greet();

    std::cout << "\n";

    {
        // 3. 孩子也得到了一个指向宠物的 "引用"。
        //    这又创建了一个 shared_ptr，作用域限定在花括号内。
        std::shared_ptr<Pet> kids_ptr = dads_ptr;
        std::cout << "Rex's reference count: " << dads_ptr.use_count() << "\n"; // 引用计数变为 3
        
        kids_ptr->greet();

        std::cout << "\n";
    } // 花括号结束，kids_ptr 被销毁。
    
    std::cout << "The kid has moved out.\n";
    std::cout << "Rex's reference count: " << dads_ptr.use_count() << "\n"; // 引用计数变回 2

    std::cout << "\n";

    // 4. 爸爸搬走了。
    //    我们将他的指针重置为空。
    dads_ptr.reset();
    std::cout << "Dad has moved out.\n";
    std::cout << "Rex's reference count: " << moms_ptr.use_count() << "\n"; // 引用计数变回 1

    std::cout << "\n";

    // 5. 妈妈是最后一个拥有宠物的人。
    //    当妈妈的指针也消失时...
    std::cout << "Mom is the last one.\n";
    moms_ptr.reset();
    // moms_ptr 被重置，引用计数从 1 降为 0。
    // 此时，Pet 对象会自动被销毁。
    
    std::cout << "\nNow, no one owns the pet.\n";

    return 0;
}

运行结果：

Pet 'Rex' has been adopted!
Rex's reference count: 1
Rex says Woof!

Rex's reference count: 2
Rex says Woof!

Rex's reference count: 3
Rex says Woof!

The kid has moved out.
Rex's reference count: 2

Dad has moved out.
Rex's reference count: 1

Mom is the last one.
Pet 'Rex' has been sent to the shelter.

Now, no one owns the pet.

1. 自动的生命周期管理： Pet 对象 “Rex” 的生命周期与 shared_ptr 紧密绑定。我们作为程序员，完全不需要手动调用 delete。
2. 引用计数 (Reference Counting)： 每当一个新的 shared_ptr 通过拷贝指向 “Rex” 时，引用计数 use_count() 就会增加。每当一个 shared_ptr 被销毁或重置时，引用计数就会减少。
3. 共享所有权 (Shared Ownership)： 爸爸、妈妈和孩子都“拥有”这只宠物。shared_ptr 完美地模拟了这种共享关系。
4. 资源在最后一位所有者离开时被释放： 只有当引用计数从 1 降到 0 的那一刻（当 moms_ptr 被重置时），Pet 对象的析构函数 ~Pet() 才被调用。在此之前，即使爸爸和孩子都“离开”了，宠物 “Rex” 依然安全地存在着。

这个简单的例子就是 std::shared_ptr 最核心的用途：当你有一个资源，它的生命周期不应该由某个单一的对象或函数来决定，而是应该持续存在，直到所有关心它的“人”都不再需要它为止。

item20：当std::shared_ptr可能悬空时使用std::weak_ptr

std::weak_ptr 是一种非拥有 (non-owning) 的智能指针。它的核心作用可以概括为：

1. 观察者：它可以“观察”一个由 std::shared_ptr 管理的对象，但不参与其生命周期管理。也就是说，weak_ptr 的存在与否，不会影响对象的引用计数，也不会阻止对象被销毁。
2. 安全检查器：它提供了一种安全的方式来检查所观察的对象是否仍然存在。
3. 循环引用破坏者：它是打破 shared_ptr 之间循环引用的标准解决方案。

可以把 weak_ptr 想象成一个持有音乐会门票票根的人。他可以通过票根知道曾经有一场音乐会，但票根本身并不能让音乐会继续进行。如果音乐会结束了（对象被销毁了），票根就失效了。

循环引用

为什么需要weak_ptr？

举例：

#include <memory>

class Child;

class Parent {
public:
    std::shared_ptr<Child> child;
};

class Child {
public:
    std::shared_ptr<Parent> parent; // 这里导致了循环引用
};

void createCircularReference() {
    auto p = std::make_shared<Parent>();
    auto c = std::make_shared<Child>();

    p->child = c; // Parent 指向 Child
    c->parent = p; // Child 指向 Parent
} // 函数结束，局部变量 p 和 c 被销毁

1. p 和 c 被创建时，Parent 和 Child 对象的强引用计数都为 1。
2. p->child = c; 使得 Child 对象的强引用计数变为 2。
3. c->parent = p; 使得 Parent 对象的强引用计数变为 2。
4. createCircularReference函数结束，局部变量p和c被销毁。Parent 和 Child 对象的强引用计数各自从 2 减为 1。
5. 问题来了：Parent 对象仍然被 Child 对象内部的 shared_ptr 指着，所以它的引用计数是 1。Child 对象也仍然被 Parent 对象内部的 shared_ptr 指着，所以它的引用计数也是 1。
6. 结果：它们的引用计数永远无法降到 0。Parent 和 Child 对象的析构函数永远不会被调用，导致内存泄漏

weak_ptr如何打破循环

weak_ptr 的“非拥有”特性正是解决这个问题的关键。在对象关系中，我们必须指定一方是“强”关系（拥有），另一方是“弱”关系（观察）。通常，在“整体-部分”或“父-子”关系中，让“部分”或“子”对“整体”或“父”持有弱引用。

修复后的代码：

class Parent; // 前向声明

class Child {
public:
    // Child 不拥有 Parent，只是知道谁是它的 Parent
    std::weak_ptr<Parent> parent; // 使用 weak_ptr！
};

class Parent {
public:
    // Parent 拥有 Child
    std::shared_ptr<Child> child;
};

void createHealthyReference() {
    auto p = std::make_shared<Parent>();
    auto c = std::make_shared<Child>();

    p->child = c;
    c->parent = p; // 将 shared_ptr 赋给 weak_ptr 是安全的
}

1. p 和 c 被创建时，Parent 和 Child 对象的强引用计数都为 1。
2. p->child = c; 使得 Child 对象的强引用计数变为 2。
3. c->parent = p; weak_ptr 不会增加 Parent 对象的强引用计数！ Parent 的强引用计数仍然是 1。（Parent 的弱引用计数会 +1，但这不影响生命周期）。
4. createHealthyReference 函数结束，局部变量 p 和 c 被销毁。
5. p 被销毁，Parent 对象的强引用计数从 1 降为 0。Parent 对象被安全销毁！
6. 在 Parent 的析构函数中，其成员 p->child (一个指向 Child 的 shared_ptr) 被销毁。
7. Child 对象的强引用计数从 2 降为 1。
8. c 被销毁，Child 对象的强引用计数从 1 降为 0。Child 对象被安全销毁！

结论： 内存泄漏问题被完美解决。

如何使用 weak_ptr？—— lock() 是关键

你不能像 shared_ptr 或裸指针那样直接解引用 weak_ptr (* 或 ->)，因为它指向的对象可能已经被销毁了。直接访问是不安全的。

weak_ptr 提供了一个核心方法 .lock() 来安全地访问对象：

• weak_ptr.lock() 会检查被观察的对象是否还存活。
• 如果对象存活，.lock() 会返回一个指向该对象的有效的 std::shared_ptr。这个返回的 shared_ptr 会使对象的强引用计数 +1，确保在你使用它的期间，对象不会被销毁。
• 如果对象已被销毁，.lock() 会返回一个空的 std::shared_ptr。

void useChild(const Child& c) {
    std::cout << "Trying to access parent from child...\n";
    
    // 使用 .lock() 获取一个临时的 shared_ptr
    if (auto shared_p = c.parent.lock()) {
        // if 语句块内，shared_p 是一个有效的 shared_ptr
        // Parent 对象在此期间是安全的
        std::cout << "Parent exists! Accessing it.\n";
        // ... 可以安全地使用 shared_p ...
    } else {
        // 如果 .lock() 返回空指针，说明 Parent 对象已经被销毁了
        std::cout << "Parent has been destroyed.\n";
    }
}

缓存

除了打破循环引用，weak_ptr 非常适合实现缓存。

场景：假设你有一个工厂，它根据 ID 从数据库加载非常大的 Widget 对象。为了避免重复加载，你想把加载过的 Widget 缓存起来。

• 如果缓存使用 std::shared_ptr<Widget>：那么只要对象在缓存中，它就永远不会被销毁，即使程序中其他所有地方都不再需要它了。这可能导致缓存无限增大，最终耗尽内存。
• 如果缓存使用 std::weak_ptr<Widget>：缓存只“观察”对象。当程序中所有对 Widget 的 shared_ptr 都消失后，Widget 对象会被正常销毁。缓存中的 weak_ptr 随之失效。下次请求时，缓存发现 weak_ptr 失效了，就知道需要重新从数据库加载。

这完美地实现了“当对象仍在使用时，从缓存中快速获取；当对象不再被使用时，自动从缓存中移除”的逻辑。

item21：优先考虑使用make_unique和make_shared而非new

在现代 C++ 中，直接使用 new 来创建对象然后将其传给智能指针的构造函数，是一种过时且有风险的做法。

旧的、不推荐的方式：

auto spw = std::shared_ptr<Widget>(new Widget); // 使用 new
auto upw = std::unique_ptr<Widget>(new Widget); // 使用 new

现代的、推荐的方式：

auto spw = std::make_shared<Widget>(); // 使用 make_shared
auto upw = std::make_unique<Widget>(); // 使用 make_unique (C++14+)