当前位置：首页 > ds >正文

CppCon 2018 学习:Surprises In Object Lifetime

ds 2025/7/6 17:02:30

1. 什么是对象（Object）？

在 C++ 中，对象是一个数据类型的实例。更具体地说，它是占用内存的某个区域，并且具有一个特定的类型。一个对象可以是一个简单的变量（例如 int 类型），也可以是一个结构体（struct），或者更复杂的数据类型，比如数组或类。
当我们说某个东西是“对象”时，通常指的是某个已命名或未命名的实体，它在内存中占用空间，并且有一个类型。

2. `int` 与包含 `int` 的结构体有什么不同？

在你提供的代码示例中：

struct S { int i; };
int i;

int i; 是一个简单的整数变量，它直接存储一个整数值。
struct S { int i; }; 定义了一个结构体 S，它包含一个整数 i。所以，S 是一个包含 int 的类型，它不只是一个整数，而是一个更复杂的类型，可以包含多个成员（例如 int、double 或其他类型）。
主要区别在于组成和类型：
int i; 是一个原始数据类型，它直接存储值。
struct S 是一个类型，它包含一个 int，但它本身是一个 S 类型的对象，可以包含多个成员。

3. 统一初始化语法（Uniform Initialization Syntax）

在你提供的代码中，使用了统一初始化语法（{}），这是 C++11 引入的：

S s{15};  // 使用15初始化结构体S中的成员i
int i{15}; // 使用15初始化整数i

通过统一初始化语法，我们可以对简单类型和复杂类型（如结构体）进行相同的初始化方式。但注意，S s{15}; 和 int i{15}; 的行为还是不同的，因为它们的类型不同。

4. 静态断言与类型特征（Static Assertions and Type Traits）

你提供的代码中使用了 static_assert 来检查类型的某些属性，这些检查是在编译时进行的：

static_assert(std::is_trivially_constructible_v<S>);
static_assert(std::is_trivially_constructible_v<int>);
static_assert(std::is_trivially_destructible_v<S>);
static_assert(std::is_trivially_destructible_v<int>);
static_assert(std::is_trivially_copyable_v<S>);
static_assert(std::is_trivially_copyable_v<int>);
static_assert(std::is_object_v<S>);
static_assert(std::is_object_v<int>);

这些断言检查的是：

std::is_trivially_constructible：检查类型是否可以用简单的方式构造。
std::is_trivially_destructible：检查类型是否可以用简单的方式析构。
std::is_trivially_copyable：检查类型是否可以简单地进行字节拷贝。
std::is_object：检查类型是否为对象（包括像 int 这样的基本类型）。
对于 S 和 int 两者，这些类型特性都成立：
它们都可以简单地构造和析构。
它们都可以简单地拷贝。
它们都被视为“对象”类型。
因此，尽管 S 和 int 类型不同，但在某些基础的类型特性上它们是相同的。

总结

对象（Object）：在 C++ 中，对象是任何拥有数据和类型的实体。
int 与 struct S 的区别：int 是一个简单的基本类型，直接保存一个整数值；而 struct S 是一个包含 int 的复合类型，它可以包含多个成员。
统一初始化语法：它使得简单类型和复杂类型的初始化语法变得一致，但它们的行为仍然有差异。
类型特性：断言显示了 S 和 int 都有一些相同的属性，例如可以简单地构造、析构和拷贝，它们都被认为是对象。
这样解释清楚了吗？如果还有什么不明白的地方，随时告诉我！

#include <iostream>
#include <type_traits>  // 引入类型特性检查的头文件
// 定义一个结构体 S，包含一个整数成员 i
struct S {int i;
};
// 函数 use_s 用于演示结构体和原始类型之间的差异
int use_s() {// 静态断言：检查 struct S 和 int 的大小是否相同（这里只是为了演示，实际上它们的大小可能不同）static_assert(sizeof(S) == sizeof(int), "Sizes do not match!");// 初始化结构体 S，成员 i 被赋值为 15S s{15};// 通过 reinterpret_cast 强行将结构体 S 的内存区域解释为 int 类型引用// 这种做法不推荐在实际代码中使用，它可能会引发未定义行为int &i = reinterpret_cast<int &>(s);// 将通过 reinterpret_cast 得到的引用 i 设置为 23// 实际上，这会修改结构体 S 内部的整数 ii = 23;// 返回结构体 S 中的整数值 ireturn s.i;
}
// 函数 use_int 用于演示原始类型 int 的操作
int use_int() {// 静态断言：检查 int 类型的大小是否与 int 本身相同（此处只是为了演示）static_assert(sizeof(int) == sizeof(int), "Sizes do not match!");// 初始化整数 s，赋值为 15int s{15};// 同样，使用 reinterpret_cast 将整数 s 强制转换为 int 类型引用int &i = reinterpret_cast<int &>(s);// 将 i 的值设置为 23// 实际上，这会直接修改整数 s 的值i = 23;// 返回整数 i 的值return i;
}
int main() {// 调用 use_s() 函数并输出其返回值std::cout << "use_s() returns: " << use_s() << std::endl;// 调用 use_int() 函数并输出其返回值std::cout << "use_int() returns: " << use_int() << std::endl;// 使用静态断言来检查类型特性static_assert(std::is_trivially_constructible_v<S>,"S is not trivially constructible");  // 检查 S 是否是平凡构造的static_assert(std::is_trivially_constructible_v<int>,"int is not trivially constructible");  // 检查 int 是否是平凡构造的static_assert(std::is_trivially_destructible_v<S>,"S is not trivially destructible");  // 检查 S 是否是平凡析构的static_assert(std::is_trivially_destructible_v<int>,"int is not trivially destructible");  // 检查 int 是否是平凡析构的static_assert(std::is_trivially_copyable_v<S>,"S is not trivially copyable");  // 检查 S 是否是平凡拷贝的static_assert(std::is_trivially_copyable_v<int>,"int is not trivially copyable");  // 检查 int 是否是平凡拷贝的static_assert(std::is_object_v<S>,"S is not considered an object");  // 检查 S 是否是一个对象类型static_assert(std::is_object_v<int>,"int is not considered an object");  // 检查 int 是否是一个对象类型return 0;
}

标准是怎么说的？

在 C++ 标准的 [basic.types (8)] 部分中，定义了什么是“对象类型”。让我们逐步解析这段定义：

一个对象类型是（可能带有 cv 限定符的）类型，它既不是函数类型，也不是引用类型，也不是 cv 修饰的 void 类型。

这意味着什么？

对象类型指的是：

不是函数类型：
- 函数类型（例如 int()、void(int) 等）不被视为对象类型。函数是一种特殊的实体，能够被调用，但它并不代表传统意义上的在内存中占用空间的数据对象。
不是引用类型：
- 引用类型（例如 int&、float&&）也不算作对象类型。引用只是另一个对象的别名，它本身不在内存中存储数据，只是指向另一个对象。
不是 void 类型：
- void 类型不是对象类型。void 是一个特殊类型，表示“没有类型”，通常用作函数返回类型或指示没有数据。它并不描述一个实际的内存对象。

那么，什么是对象类型？

对象类型是指表示一个实际存储在内存中的对象的类型，它占有内存并且有大小，除了以下几种类型：

函数类型（因为函数不是数据对象，而是可以调用的实体）。
引用类型（因为引用不直接存储数据，它只是指向其他对象）。
void 类型（因为 void 不表示任何数据，它没有大小，也没有内存表示）。

对象类型的示例：

基础数据类型：int、float、double、char 等。
结构体：struct MyStruct { int i; };。
类：class MyClass { int x; };。
数组：int arr[10];。
指针：int* ptr;。

不是对象类型的示例：

函数类型：int()、void(int) 等。
引用类型：int&、float&&。
void 类型：void 本身不是对象类型。

总结：

在 C++ 中，对象类型指的是任何代表一个占用内存、并且有大小的实体的类型，除了以下几种情况：

函数类型（因为它们不是数据对象，而是可调用的实体）。
引用类型（它们没有自己的内存，只是指向其他对象）。
void 类型（它不代表数据）。

对象生命周期

在 C++ 标准中，对象的生命周期是指从对象的创建到销毁的整个过程。这个过程涉及到内存的分配、初始化、销毁等多个阶段。标准中的 [basic.life] 部分详细描述了对象生命周期的开始和结束。

1. 生命周期开始

生命周期的开始在标准中有以下几个条件：

对象类型 T 的生命周期开始时：

1.1 获取具有适当对齐和大小的内存空间。

1.2 如果对象具有非空初始化（即初始化过程中有实际数据赋值），则初始化完成。

解释：

内存分配：对象生命周期的开始标志是为该对象分配了内存，并且内存的对齐方式和大小符合该对象类型的要求。
初始化：如果对象有初始化操作（如构造函数），初始化必须完成。需要注意的是，对于联合体成员或其子对象，只有当该联合体成员被初始化时，生命周期才算开始。
- 联合体的特殊情况：对于联合体而言，如果多个成员共享同一块内存空间，那么只有当某个特定成员被初始化时，该成员的生命周期才会开始。

例如：

union MyUnion {int x;double y;
};
MyUnion u; // 只有 u.x 或 u.y 被初始化时，生命周期才开始

2. 生命周期结束

生命周期的结束有以下几个条件：

对象类型 T 的生命周期结束时：

1.3 如果 T 是一个类类型并且有非平凡的析构函数（即需要自定义析构操作），当析构函数开始执行时，生命周期结束。

1.4 当对象占用的存储空间被释放，或者被另一个对象所重用时，生命周期也结束，前提是该新对象不是嵌套在原始对象内部。

解释：

析构函数：如果对象是一个类类型，并且该类具有非平凡的析构函数（即类没有默认析构函数，或者析构函数有自定义行为），那么对象的生命周期会在析构函数开始时结束。
- 例如，如果一个对象的析构函数涉及资源清理（如释放内存、关闭文件等），那么该清理操作标志着对象生命周期的结束。
内存释放与重用：对象的生命周期也会在其占用的内存空间被释放或重用时结束。特别是如果内存被另一个非嵌套对象重新利用时，原对象的生命周期就结束了。
- 嵌套对象：如果一个对象包含另一个对象（例如类内成员），那么内存空间的释放不一定会导致内外对象生命周期的同时结束。嵌套对象的生命周期会依赖于外部对象。

例如：

class MyClass {
public:~MyClass() { /* 析构操作 */ }
};
MyClass obj;  // 生命周期开始时为 obj 分配内存
// 当 ~MyClass() 执行时，生命周期结束

3. 总结

生命周期开始：在对象获得合适的内存（对齐和大小）后，并且如果有初始化操作时，初始化必须完成，生命周期才会开始。
生命周期结束：当对象的析构函数执行时，或者对象的内存被释放、重用时，生命周期结束。
理解这些规则有助于更好地管理对象的内存和资源，尤其是在涉及动态内存管理和自定义析构时。

Basic Object Lifetime（基本对象生命周期）

在这些代码示例中，我们主要探讨了 对象生命周期 和 对象的构造与销毁过程。我们来逐一分析每段代码的输出。

代码 1:

#include <cstdio>
struct S {S() { puts("S()"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
int main() {S s;  // S(){S s2{s};  // S(const S &)}           // ~S()
}             // ~S()

分析：

当对象 s 被创建时，调用了 构造函数 S()，输出 S()。
在代码块内，创建了一个新的对象 s2，它是通过 拷贝构造函数 从 s 初始化的，输出 S(const S &)。
s2 的生命周期在代码块结束时结束，因此 析构函数 被调用，输出 ~S()。
最后，程序结束时，s 的生命周期结束，析构函数再次被调用，输出 ~S()。
输出：

S()
S(const S &)
~S()
~S()

代码 2:

#include <cstdio>
struct S {S() { puts("S()"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
int main() {S s;  // S(){[[maybe_unused]] S &s2{s};  // 注意：引用类型没有生命周期}  // ~S()
}

分析：

S s; 的创建，调用了 构造函数 S()，输出 S()。
在代码块内，创建了一个引用 s2，它是 s 的引用。需要注意，引用类型（如 S&）本身并没有生命周期，它只是对已存在对象的别名。因此 不会调用拷贝构造函数。
由于 s2 是引用类型，它并不会在作用域结束时销毁，只有 s 的析构函数会在作用域结束时被调用，输出 ~S()。
输出：

S()
~S()

代码 3:

#include <cstdio>
struct S {S() { puts("S()"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
int main() {S s;  // S(){[[maybe_unused]] S &s2{s};  // 只创建引用，不会调用拷贝构造函数}  // ~S()
}  // ~S()

分析：

这一段和 代码 2 类似。s2 是 s 的引用，它不会触发拷贝构造函数。代码块结束时，只有 s 被销毁，因此输出 S() 和 ~S()。
输出：

S()
~S()

代码 4:

#include <iostream>
const int &get_data() {const int i = 5;return i;  // 返回 i 的引用
}
int main() {std::cout << get_data();  // 输出 i 的值
}

分析：

get_data 函数定义了一个 局部变量 i，并返回 i 的引用。i 的生命周期仅在 get_data 函数内有效。
当 get_data 函数返回时，i 的生命周期结束，返回的引用变得悬空（即 悬挂引用）。此时访问 i 是 未定义行为，会导致程序崩溃或未定义的输出。
因此，正确答案是 未定义行为，程序可能输出垃圾值，或者直接崩溃。

总结：

引用类型（如 S&）本身并不具有生命周期，它仅仅是另一个对象的别名。所以引用类型不会触发对象的生命周期管理（如拷贝构造或析构）。
对于 局部变量的引用（如 get_data 返回的引用），如果引用的是一个局部变量，它会在局部变量生命周期结束时变得悬挂，访问它会导致未定义行为。

问题分析：

你提供的代码涉及到一个返回 引用包装器（std::reference_wrapper）的函数，其中包装的引用指向一个 局部变量。这个问题和之前的 悬挂引用 问题类似，只是我们用 std::reference_wrapper 来包装引用。

代码：

#include <iostream>
#include <functional>
std::reference_wrapper<const int> get_data() {const int i = 5;return std::ref(i);  // 使用 std::ref 包装引用
}
int main() {std::cout << get_data();  // 输出引用包装的值
}

分析：

get_data 函数声明了一个 局部常量变量 i，并返回 i 的引用包装器 std::reference_wrapper<const int>。
返回的引用（包装在 std::reference_wrapper 中）指向的是 局部变量 i，而这个变量的生命周期只在 get_data 函数内部有效。返回它的引用会导致 悬挂引用，因为函数结束时，局部变量 i 被销毁，返回的引用就不再有效。
当我们尝试在 main 函数中输出 get_data() 返回的引用时，访问已经销毁的对象会导致未定义行为。

实际输出：

未定义行为（UB）：虽然 std::reference_wrapper 将引用包装起来，但它不能改变对象的生命周期。由于 i 的生命周期在函数结束时就结束，访问它会导致未定义行为。输出的内容是无法预测的，可能是垃圾值、崩溃，或者某些看起来有效的输出，但无法保证它的正确性。

警告：

通常，编译器会发出警告，提示我们 返回了指向栈内存的引用。具体警告内容可能是：

warning: reference to stack memory returned

或者类似的警告，意思是：返回的引用指向了一个栈上的局部变量，这个局部变量在函数结束时将不再有效。

总结：

输出：由于返回的是悬挂引用，输出是未定义的，可能是垃圾值、崩溃，或者其他不可预知的结果。
警告：编译器通常会警告我们“返回了指向栈内存的引用”，这是因为局部变量的生命周期在函数结束时就结束了。

注意：

使用 std::reference_wrapper 包装引用并不会延长被引用对象的生命周期。为了避免此类问题，通常我们需要返回对象的副本，或者确保返回的引用始终指向有效的内存。

问题背景：

代码中使用了 std::reference_wrapper<const int> 来包装一个 局部变量 i 的引用，并返回这个包装器。但是 i 的生命周期仅限于 get_data 函数的作用域，因此返回该引用包装器会导致 悬挂引用（dangling reference），这是未定义行为。

具体分析：

你提到的警告，取决于使用的编译器（例如 Clang 和 GCC）可能会有所不同。以下是对问题的详细解释：

代码：

#include <iostream>
#include <functional>
std::reference_wrapper<const int> get_data() {const int i = 5;return std::ref(i);  // 返回对局部变量 i 的引用包装
}
int main() {std::cout << get_data();  // 输出引用包装的值
}

分析：

i 是在 get_data 函数内声明的局部变量。它在函数结束时会被销毁。
std::reference_wrapper<const int> 只是将引用包装起来，它并不会延长被引用对象的生命周期。
因此，当 get_data 返回引用包装器后，引用指向的对象（i）已经不再存在了，这会导致 悬挂引用。
当你试图访问这个已经被销毁的对象时，会发生 未定义行为，这可能会导致程序崩溃、错误的输出，或者其他奇怪的现象。

编译器的行为：

不同编译器可能会以不同的方式处理这个问题：

Clang/GCC 的警告：

Clang 和 GCC 都可能会给出类似的警告，但表现上可能会有所不同。通常，它们会警告你 返回了指向栈内存的引用，因为局部变量 i 的生命周期在函数结束时就结束了。
Clang 可能会给出如下警告：
```
warning: returning reference to local variable 'i' which is a stack object
```
GCC 的警告信息也类似，通常是：
```
warning: reference to local variable 'i' returned
```

警告的含义：

这类警告意味着你正在返回一个指向 栈上对象 的引用，而栈上的对象在函数返回后会被销毁。
因此，引用包装器将变得悬挂，这将导致未定义行为，警告是编译器对这种潜在问题的提醒。

如何修复：

为了避免这个问题，应该避免返回指向局部变量的引用。如果确实需要返回引用，可以考虑以下解决方案：

返回对象副本：
如果没有特殊原因需要返回引用，可以返回一个值副本，确保生命周期是完全可控的。
```
int get_data() {const int i = 5;return i;  // 返回副本
}
```
使用 static 修饰局部变量：
如果你需要返回一个持久的引用，可以将局部变量声明为 static，这样它的生命周期就可以跨越函数调用。
```
std::reference_wrapper<const int> get_data() {static const int i = 5;return std::ref(i);  // 返回静态变量的引用包装
}
```

总结：

你遇到的警告是因为 返回了指向栈内存的引用。由于局部变量的生命周期仅限于函数内部，返回对局部变量的引用是危险的，可能会导致悬挂引用。
编译器（如 Clang 或 GCC）会发出警告，提醒你返回了指向栈内存的引用，可能导致未定义行为。
为了避免这个问题，可以选择返回副本或者使用 static 变量来延长局部变量的生命周期。

问题解析：

让我们逐步分析代码并解释其行为，特别是关于 std::string_view 和 字符串字面量 的使用。

代码示例 1：

#include <string>
#include <iostream>
const char* get_data() {return "Hello World";
}
int main() {std::cout << get_data();
}

输出：

Hello World

为什么这个是允许的？

字符串字面量（例如 "Hello World"）的类型是 const char[12]，并且它在程序中的生命周期是 静态的（static storage duration）。这意味着它在程序的整个生命周期内都是有效的。
get_data() 返回一个指向该字符串字面量的指针。由于字符串字面量的生命周期始终存在，指针指向的内存区域是有效的，所以返回指针是安全的。

代码示例 2：

#include <string>
#include <iostream>
std::string_view get_data() {return "Hello World";
}
int main() {std::cout << get_data();
}

输出：

Hello World

解释：

std::string_view 是一个轻量级的非拥有式字符串视图。它本质上由两个指针（指向字符数据和长度）构成。
在这个例子中，std::string_view 将会指向 const char[] 类型的字符串字面量 "Hello World"。字符串字面量是静态存储的，因此 std::string_view 指向的数据不会在程序运行期间消失。
输出 Hello World 是正常的，因为 std::string_view 只是持有对现有内存区域的引用，并没有尝试管理该内存。

代码示例 3：

#include <string>
#include <iostream>
std::string_view get_data() {std::string s = "Hello World";return s;
}
int main() {std::cout << get_data();
}

输出：

未知（通常是垃圾值）**

为什么输出是未知的？

这里的 std::string_view 返回一个指向局部变量 s 数据的引用。s 是一个 局部 std::string 对象，它的生命周期只在 get_data() 函数内有效。
当 get_data() 函数返回时，s 的内存被销毁，而 std::string_view 持有的指针将指向一个已经释放的内存区域，这就是 悬挂引用。
由于访问已被销毁的内存，结果是 未定义行为，即输出会是未知的垃圾值。

警告信息：

编译器通常会给出以下警告，警告我们返回了一个 悬挂引用：

warning: returning reference to local variable 's' which is a stack object

意思是返回了指向局部变量的引用，而局部变量 s 在函数结束后会被销毁。

总结：

字符串字面量 (const char*) 返回值：
- 字符串字面量有 静态存储持续时间，因此它们在程序结束前始终有效。返回指向字符串字面量的指针是安全的。
std::string_view 与字符串字面量：
- std::string_view 只是一个轻量级的引用，它可以安全地指向字符串字面量，因为字符串字面量的生命周期与程序的生命周期一致。
std::string 和 std::string_view：
- 如果将 std::string 传递给 std::string_view，它会返回指向栈上的局部对象的数据。在函数结束后，std::string 被销毁，std::string_view 指向的内存也就不再有效，这会导致 悬挂引用，并且是 未定义行为。
警告：
- 编译器会发出警告，提示我们返回了局部对象的引用，这是因为 std::string 在函数结束后销毁，而 std::string_view 持有对该局部对象的引用。

如何修复：

如果你需要返回一个有效的字符串视图，你可以：

将 std::string 对象 声明为 static，从而延长它的生命周期。
直接返回 std::string 对象，而不是 std::string_view，如果你不想使用引用或指针。

#include <string>
#include <iostream>
std::string_view get_data() {static std::string s = "Hello World";return s;
}
int main() {std::cout << get_data();
}

这样做，s 的生命周期将会延长到程序结束，从而避免悬挂引用的问题。

代码分析：`std::string_view` 和局部数组的行为

让我们一步一步分析代码，以理解std::string_view和局部数组const char s[]之间的关系。

代码示例：

#include <string>
#include <iostream>
std::string_view get_data()
{const char s[] = "Hello World"; // 局部数组return s; // 返回 std::string_view
}
int main()
{std::cout << get_data(); // 打印结果
}

这里发生了什么？

局部数组初始化 (const char s[] = "Hello World";)
- 创建了一个局部数组 s[]，并初始化为字符串 "Hello World"。这个数组具有 自动存储持续时间，意味着它的生命周期仅限于 get_data() 函数的作用域。一旦 get_data() 返回，局部数组 s[] 将被销毁，内存也会被释放。
返回 std::string_view:
- std::string_view 对象通过 s 来初始化。由于 数组会退化为指针，所以 s 实际上退化为指向数组第一个元素的指针（类型是 const char*），这个指针被传递给 std::string_view 的构造函数。
- std::string_view 不拥有它指向的内存，它只是持有一个指针和一个长度，提供对数据的视图。问题在于，std::string_view 仍然指向局部变量 s[]，而这个局部变量在函数返回后会被销毁。

预期的行为：

当函数返回时，局部数组 s[] 被销毁。因此，返回的 std::string_view 会指向 无效内存，在 main() 中访问它时会导致 未定义行为。
程序可能看起来能够正常工作，但这并不是 可靠的，可能会导致意外的输出或崩溃。

没有警告：

令人惊讶的是，编译器并不会发出任何警告，即使代码返回了一个指向局部变量的 std::string_view，而这个局部变量的生命周期很短。
- 为什么会这样？ 这是因为编译器 无法自动检测到这个特定的问题。在 C++ 中，返回一个指向局部对象的引用（或指针）是合法的语法，但必须特别注意对象的生命周期。这是 需要静态分析工具或运行时检查来捕获此类问题。

在实践中会发生什么？

根据实现和运行时环境的不同，访问这个“悬空”的 std::string_view 可能会导致：
- 垃圾输出（例如，随机字符或垃圾值）。
- 程序崩溃（段错误）。
- 未定义行为，结果是不可预测的。

结论：

字符串的生命周期比你想象的要长 — 这对于字符串字面量和静态分配的数据是成立的。然而，在这个例子中，字符串（或字符串视图）指向的内存可能会在你不希望的时刻消失（例如在局部数组的情况下）。
但是，当它们不再有效时，我们就会遇到未定义行为。

如何修复这个问题：

将数组 s 声明为静态变量，以延长它的生命周期：

std::string_view get_data()
{static const char s[] = "Hello World"; // 现在有静态存储持续时间return s;
}

使用 std::string 替代 std::string_view：
如果目标是返回一个字符串，并且该字符串的生命周期超过函数作用域，可以考虑使用 std::string，它会自己管理内存。
```
std::string get_data()
{const char s[] = "Hello World";return s; // 返回一个 std::string，它拥有自己的数据
}
```

通过这种方式，你避免了返回一个指向局部内存的 std::string_view，结果将是定义明确且可预测的。

容器和类型析构：一个详细分析

在这段代码中，我们正在观察 std::vector 和类 S 的互动，尤其是对象的构造、移动和析构过程。通过这段代码，我们可以更清楚地了解 C++ 容器如何处理具有复杂生命周期的对象。

代码分析：

#include <cstdio>
#include <vector>
struct S {S() { puts("S()"); }                   // 默认构造函数S(int) { puts("S(int)"); }             // 带参数的构造函数S(const S &) noexcept { puts("S(const S &)"); }  // 拷贝构造函数S(S &&) noexcept { puts("S(S&&)"); }  // 移动构造函数S &operator=(const S &) { puts("operator=(const S&)"); return *this; } // 拷贝赋值S &operator=(S &&) { puts("operator=(S&&)"); return *this; }            // 移动赋值~S() { puts("~S()"); }                 // 析构函数
};
int main() {std::vector<S> vec;vec.push_back(S{1});  // 将一个临时对象推入 vector 中
}

主要操作：

临时对象的创建： S{1} 创建了一个类型为 S 的临时对象，通过 S(int) 构造函数来初始化。这会输出：
```
S(int)
```
临时对象的移动： vec.push_back(S{1}) 调用了 std::vector 的 push_back，会将临时对象移动到 vector 中，调用了 S(S&&) 移动构造函数。输出：
```
S(S&&)
```
销毁临时对象： 在 push_back 完成后，临时对象已经移动到 vector 中，它的生命周期已经结束，因此会调用临时对象的析构函数。输出：
```
~S()
```
销毁 vector 中的对象： 最后，当 main 函数结束时，vector 会被销毁，容器中的元素（即之前移动进来的对象）会被析构。输出：
```
~S()
```

预期的输出：

根据上面的分析，程序的输出应该是：

S(int)
S(S&&)
~S()
~S()

意外之处：

移动后的对象仍然需要被销毁： 尽管我们将对象从临时对象移动到了 vector 中，移动后的对象依然是有效的，且它仍然需要析构。这意味着即使对象被移动了，它的生命周期依然存在，vector 会负责销毁它。因此，在 vector 析构时，移入容器的对象的析构函数仍然会被调用。
析构时的额外开销： 对于 非平凡类型（如 S），即使对象被移动了，它依然会经过析构。并且，析构可能会做一些额外的操作，比如清理资源（如动态内存）。如果析构过程没有被内联（或者没有被优化掉），可能会带来不必要的性能开销。

总结：

移动语义： C++ 的移动语义让容器（如 std::vector）可以在不拷贝对象的情况下把它们插入到容器中，这样能有效减少不必要的性能开销。
析构： 即使是 被移动的对象，也必须经过析构，这对于资源管理至关重要。对于非平凡类型，析构过程可能包括对动态资源的释放，因此必须非常小心对象生命周期的管理。
性能和优化： 即使没有显示的拷贝构造或赋值，移动构造和析构也可能带来性能问题，尤其是在对象的析构过程比较复杂的情况下。因此在性能敏感的代码中，通常需要进一步优化。

实践建议：

对于有显式资源管理（如动态分配内存或文件句柄）的类，使用 move 语义时需要小心，确保资源被正确转移而不会引发资源泄漏。
了解容器如何管理对象的生命周期，特别是对于像 std::vector 这样的容器，在存储复杂对象时尤为重要。

`emplace_back` 和 `std::vector` 容器使用分析

在这些示例中，我们主要关注 std::vector 和 emplace_back 方法的行为，emplace_back 直接在容器内构造对象，而不是像 push_back 一样先构造好对象再传入容器。我们逐个分析不同的用法及其输出。

案例 1：使用 `emplace_back` 传递一个已经构造的对象（错误用法）

#include <cstdio>
#include <vector>
struct S {S() { puts("S()"); }S(int) { puts("S(int)"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
int main() {std::vector<S> vec;vec.emplace_back(S{1});  // 错误用法：先构造一个对象，再传递给 emplace_back
}

发生了什么？

在这个例子中，我们错误地将 S{1} 传递给 emplace_back。emplace_back 的目的是直接在容器内调用构造函数，但在这里我们先创建了一个对象，然后将它传入。

步骤 1： 创建临时对象 S{1}，调用 S(int) 构造函数。
步骤 2： 临时对象被移动到容器中，调用了 S(S&&) 移动构造函数。
步骤 3： 临时对象销毁，调用 ~S() 析构函数。

预期输出：

S(int)
S(S&&)
~S()
~S()

案例 2：正确使用 `emplace_back` 传递一个构造参数

#include <cstdio>
#include <vector>
struct S {S() { puts("S()"); }S(int) { puts("S(int)"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
int main() {std::vector<S> vec;vec.emplace_back(1);  // 正确用法：直接在容器内构造对象
}

发生了什么？

在这个例子中，我们正确地使用了 emplace_back(1)，直接传入参数来构造对象。

步骤 1： 调用 S(int) 构造函数，在容器内直接构造对象。
步骤 2： 当容器销毁时，调用 ~S() 析构函数。

预期输出：

S(int)
~S()

案例 3：使用 `emplace_back` 并传递默认构造函数

#include <cstdio>
#include <vector>
struct S {S() { puts("S()"); }S(int) { puts("S(int)"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
int main() {std::vector<S> vec;vec.emplace_back(); // 使用默认构造函数
}

发生了什么？

在这个例子中，我们使用了默认构造函数 S() 来构造对象。

步骤 1： 调用默认构造函数 S() 来在容器内直接构造对象。
步骤 2： 当容器销毁时，调用 ~S() 析构函数。

预期输出：

S()
~S()

案例 4：`emplace_back` 传递数组的引用

#include <string>
#include <iostream>
std::string_view get_data() {const char s[] = "Hello World"; // 本地数组return s;  // 返回数组的引用（被转换为指针）
}
int main() {std::cout << get_data();
}

发生了什么？

在这个例子中，我们将本地数组 s 转换为 std::string_view 类型并返回。std::string_view 内部持有的是指向字符串的指针。由于数组 s 是局部变量，当函数返回后，它的生命周期就结束了。

步骤 1： std::string_view 返回一个指向局部数组 s 的指针。
步骤 2： 在 main 函数中打印时，实际上访问的是已经不存在的数组数据，导致未定义行为。

预期输出：

未知的行为

警告：

编译器通常会给出警告，提示我们返回了指向栈上数据的引用或指针，这种做法会导致访问无效内存。

总结：

错误使用 emplace_back： 如果你已经显式地创建了一个对象并将它传给 emplace_back，它就像 push_back 一样，导致不必要的移动和复制。
正确使用 emplace_back： 应该直接在 emplace_back 中传递构造参数，这样可以避免多余的复制或移动操作。
默认构造函数： 即使不提供任何参数，emplace_back 也会调用默认构造函数在容器中构造对象。
局部数组与 std::string_view： 返回指向局部数组的 std::string_view 会导致访问已销毁的内存，造成未定义行为。

Temporaries 及其生命周期分析

在这段代码中，我们探讨了 C++ 中临时对象的生命周期扩展规则，特别是在将临时对象绑定到常量引用时的行为。

代码分析：

#include <cstdio>
struct S {S() { puts("S()"); }~S() { puts("~S()"); }
};
S get_value() { return {}; }
int main() {const auto &val = get_value();  // 临时对象绑定到引用puts("Hello World");
}

步骤解析：

get_value():
- 返回一个类型为 S 的临时对象。这个临时对象通过调用 S() 构造函数创建。
- 返回的对象生命周期默认是局部的临时对象，它会在该表达式的结束后销毁。
const auto &val = get_value();:
- 这里的关键是 const auto &，即我们将临时对象绑定到一个常量引用。
- 根据 C++ 的规则，临时对象在绑定到 const 引用时，生命周期将被延长直到引用生命周期结束。也就是说，get_value() 返回的临时对象的生命周期被延长到 val 引用的生命周期结束。
puts("Hello World");:
- 在 puts("Hello World") 被调用时，临时对象 val 依然存在，因为其生命周期被延长了。
程序结束时:
- 当程序结束时，val 引用被销毁，导致绑定的临时对象销毁，进而调用对象的析构函数 ~S()。

预期输出：

S()
Hello World
~S()

为什么会这样？

在 const auto &val = get_value(); 这一行，临时对象的生命周期被延长至 val 的生命周期结束。也就是说，get_value() 返回的临时对象不会立即销毁，而是被延长至 main 函数结束。因此，puts("Hello World") 调用时临时对象依然存在。
最后，当 main 函数结束时，val 被销毁，触发临时对象的析构，从而输出 ~S()。

重要概念：

临时对象的生命周期延长： 在 C++ 中，如果临时对象绑定到 const 引用，它的生命周期会被延长到引用生命周期结束。
复杂规则： C++ 标准规定了一些复杂的规则来处理临时对象的生命周期延长，尤其是在涉及引用时。例如，临时对象通常会在表达式结束后销毁，但如果它绑定到 const 引用，就会延长其生命周期。

总结：

这个例子展示了临时对象生命周期延长的一个常见情况。通过将临时对象绑定到常量引用，我们让对象的生命周期得到了延长，这样即使原本该在表达式结束后销毁的临时对象，在程序中仍然存活，直到引用的生命周期结束。

What’s Returned From Main?

在这段代码中，我们探讨了临时对象的生命周期延长规则，特别是如何应用到结构体成员初始化的情况下。

代码分析：

struct S {const int& m;  // 引用成员
};
int main() {const S& s = S{1};  // 临时对象绑定到常量引用return s.m;  // 返回结构体成员 m
}

详细步骤分析：

临时对象的创建：
- 在 S{1} 中，创建了一个临时对象 S，该对象的成员 m 是对 1 的引用。
- 由于 m 是引用成员，结构体 S 的构造函数会将成员 m 初始化为对 1 的引用。
生命周期延长：
- const S& s = S{1}; 这一行将临时对象 S{1} 绑定到常量引用 s 上。
- 根据 C++ 规则，临时对象的生命周期会被延长至其绑定的引用的生命周期结束。
- 因此，虽然 S{1} 是一个临时对象，但它的生命周期被延长，直到 s 的生命周期结束。
成员初始化：
- 结构体成员 m 初始化为对临时值 1 的引用。
- 在绑定到引用 s 后，临时对象的生命周期被延长，因此对 m 的引用是有效的，直到 s 被销毁。
返回值：
- return s.m; 返回的是 s 的成员 m 的值。
- m 是对 1 的引用，因此返回的值是 1。

预期输出：

代码返回 1，即 main() 函数的返回值为 1。

为什么会有这样的行为？

临时对象 S{1} 被 const S& s 引用绑定，并且由于引用延长规则，它的生命周期得到了延长。
因此，成员 m 仍然引用有效的对象 1，并且该引用在 main 函数结束时仍然有效。

生命周期延长规则的递归应用：

在 C++ 中，当一个临时对象绑定到常量引用时，该对象的生命周期会延长。然而，这个规则不仅适用于整个对象，也适用于对象的成员。
在本例中，S{1} 的生命周期通过对 const S& s 的引用延长了，但 S 的成员 m 是一个引用类型。根据 C++ 的规则，成员 m 也会遵循生命周期延长规则，因此它依然有效，并且可以正确访问 1。

总结：

这个例子展示了生命周期延长规则的递归应用，即当临时对象绑定到引用时，不仅对象本身的生命周期会延长，其成员的生命周期也会延长。这确保了对引用成员的访问在引用存在期间是有效的，即使临时对象本身已经离开了作用域。

Initializer Lists

在 C++ 中，初始化列表（Initializer Lists） 提供了一种方式，通过大括号 {} 来传递一组元素给容器或类的构造函数。

代码分析：

std::vector<std::string> vec{"a", "b"};

这行代码的目的是创建一个 std::vector<std::string> 对象 vec，并通过初始化列表 {"a", "b"} 来初始化它。

关键点：

std::initializer_list：
- 初始化列表 {"a", "b"} 本质上会被转化为 std::initializer_list<std::string>，并作为参数传递给 std::vector 的构造函数。
- std::initializer_list 是 C++11 引入的一个模板类，表示一组常量对象的数组。
内存分配：
- 代码中使用了 std::vector<std::string> 来存储字符串 "a" 和 "b"。
- std::string 在很多标准库实现中都有小字符串优化（SSO，Small String Optimization）。这意味着，如果字符串的长度较短，std::string 可能直接在其内部缓冲区中存储数据，而不需要额外的堆内存分配。
- 因此，在此例中，std::string 很可能不会为 "a" 和 "b" 进行额外的堆内存分配，特别是它们的长度较小。
动态内存分配：
- std::vector<std::string> 本身需要为其元素分配内存空间，但对于小的字符串（如 "a" 和 "b"），std::string 可能会使用其内建的优化机制，因此我们不一定会看到两次内存分配。
- 由于 std::vector 会有一个分配器来管理元素存储，std::string 的“内部”优化可能避免了对字符串本身的动态分配。

Surprise!

“std::string 是高度优化的，不要低估它”
这个意外的结果提醒我们，现代 C++ 标准库中的 std::string 类已经经过了高度的优化，特别是针对短字符串的优化。许多实现（例如 GCC、Clang 和 MSVC）都采用了小字符串优化（SSO）来避免为短字符串进行堆内存分配。实际上，像 "a" 和 "b" 这样的短字符串可能会直接在 std::string 对象内部存储，而不会涉及到额外的堆分配。

总结：

初始化列表（std::initializer_list）让我们能够方便地将元素传递给容器或对象的构造函数，尤其在处理类似 std::vector 和 std::string 这样的类时非常有用。
std::string 的小字符串优化意味着短字符串的存储会尽量避免堆内存分配，从而提高了性能。
即使看起来可能会有多个内存分配，实际情况可能因为优化而减少内存分配的次数，特别是在使用短字符串时。

理解 `std::initializer_list` 和动态内存分配

在这个例子中，我们主要讨论了 std::initializer_list 的行为以及它背后可能隐藏的动态内存分配。我们来逐步分析一下。

代码分析：

std::vector<std::string> vec{"a long string of characters","b long string of characters"
};

在这里，我们创建了一个 std::vector<std::string>，并通过大括号初始化列表传入了两个字符串字面量。这些字面量会隐式地被包装在一个 initializer_list<std::string> 中，并被 vector 构造函数使用。

关键点：

std::initializer_list 隐藏数组：
- initializer_list 内部通过创建一个隐藏数组来存储传递给它的元素（在本例中为字符串）。
- 这个 initializer_list 是一个常量数组，它提供了一个对元素的视图。
内存分配：
- 第 1 步： 创建 initializer_list 的隐藏数组（__data[]），该数组存储字符串字面量的引用。
```
const std::string __data[] = {"a long string of characters", "b long string of characters"
};
```
  这里进行了一次分配，用于存储隐藏数组。
- 第 2 步： std::vector 为它自己的内部存储分配内存。也就是说，vector 需要分配一块内存来存储这两个字符串。
- 第 3 步和第 4 步： 当 std::vector 复制来自 initializer_list 的元素时（复制字符串字面量的引用），会进行两次额外的内存分配，将字符串内容复制到 vector 的内部存储中。

最终的分配次数：

第 1 次分配： 为隐藏的 __data[] 数组分配内存。
第 2 次分配： 为 std::vector 的内部存储分配内存。
第 3 次分配： 将第一个字符串（“a long string of characters”）复制到 vector 内部存储中。
第 4 次分配： 将第二个字符串（“b long string of characters”）复制到 vector 内部存储中。

完全的内存分配分析：

分配 1：__data[] 数组存储了字符串字面量的引用。
分配 2：std::vector 创建了它的内部存储。
分配 3 和 4：将字符串字面量的内容复制到 vector 的内部存储中。

惊讶！

这里的惊讶点是，std::initializer_list 调用内部会创建一个隐藏的 const 数组，而这个数组本身也会进行内存分配。即便我们传入的只是字符串字面量，但系统仍会创建额外的分配来处理 initializer_list 和 vector 的元素。

为什么这很重要？

隐藏的内存分配： 开发者可能没有意识到，使用 initializer_list 会带来一些隐藏的内存分配，尤其是在与容器（如 std::vector）配合使用时。尽管我们传递的是字面量（静态的），但背后系统会创建额外的分配来处理 initializer_list 和 vector 的元素。
性能优化： 在某些情况下，特别是当处理大量元素或大字符串时，这种隐藏的内存分配可能会影响性能。理解这个底层行为对于编写更高效的代码至关重要。

总结：

std::initializer_list 自动创建一个隐藏数组来存储它的元素。
对于 std::vector，这会导致多次内存分配：
1. 为隐藏的数组分配内存。
2. 为 vector 的内部存储分配内存。
3. 为每个元素分配内存，并将其复制到 vector 内部存储中。
  这个过程中的隐藏分配可能让我们误以为 initializer_list 是轻量级的，但实际上它涉及到额外的内存操作，这可能会影响程序的性能。

`std::array` 和内存分配

在C++中，std::array 是一个固定大小的容器，提供了比 std::vector 更高效的内存分配和存取操作。特别是在C++17中，std::array 支持类模板类型推导，这让它的使用更加简便，但这也引发了一些关于内存分配的问题。

分析 `std::array` 初始化：

1. `std::array` 类型推导：

std::array a{"a long string of characters", "b long string of characters"};

这行代码会让编译器推导出 std::array<const char *, 2> 类型。推导的结果是：

std::array 会存储 const char * 类型的元素。
std::array 的大小为 2，因为我们传入了两个字符串字面量。

2. 内存分配：

对于 std::array<const char *, 2>：
- std::array 本身不需要动态分配内存。它是一个静态大小的容器（这里的大小为2），因此它的内部数据结构是固定的。
- 没有动态分配发生。所有元素都是指向静态字符串字面量的指针，字面量的内存管理由编译器保证，整个程序的生命周期内都有效。

3. 更复杂的 `std::array<std::string, 2>`：

std::array<std::string, 2> a{"a long string of characters","b long string of characters"
};

这个例子与前一个不同，std::array 的元素类型是 std::string，而不是 const char *。
动态内存分配会发生，因为 std::string 是一个动态分配内存的类型。
- 第一步：std::array 会分配固定大小的内存来存储两个 std::string 对象。
- 第二步：每个 std::string 对象会通过其构造函数分配内存来存储各自的字符数据（字符串字面量的拷贝）。
  因此，这里将发生 2 次动态分配：分别为两个 std::string 对象分配内存来存储字符串内容。

4. `std::array` 的效率：

std::array 的设计非常高效，因为它没有复杂的构造函数，它只在栈上分配一个固定大小的数组。这意味着：

没有额外的内存管理，所有元素都在 std::array 内部存储。
它的内存模型简单，不需要像 std::vector 那样在需要时进行内存重分配。
事实上，std::array 看起来像是一个 固定大小的数组封装，它没有动态内存分配的开销，这使得它非常高效。

总结：

std::array 的内部结构：
- 它有一个固定大小的数组来存储元素，没有动态分配内存。
- 如果元素类型是 std::string 或其他需要动态分配内存的类型，std::array 内部依然会为这些元素提供固定空间，但元素本身会依赖各自的构造函数来管理内存。
类型推导：
- 当使用 C++17 类模板类型推导时，std::array 会自动推导出合适的类型，像 std::array<const char *, 2>，而这个类型在栈上是固定的，不需要额外的内存分配。
最优性能：
- std::array 没有复杂的构造函数，因此它非常高效，特别是在存储固定大小的简单类型时（如 const char * 或其他 POD 类型）。它几乎没有任何内存管理的开销。

惊讶！

std::array 没有构造函数！
- 它的实现非常简单，只有一个固定大小的数组。这使得它在性能上非常出色，因为没有涉及到动态分配、构造函数或析构函数的复杂逻辑。
  这种设计是为了解决标准库中对效率的高度需求，尤其是在不需要动态内存的场景下。

Ranged-for Loops 和引用生命周期

在 C++ 中，ranged-for 循环 是一种简便的语法，用来遍历容器中的元素。然而，在使用引用类型时，涉及到对象生命周期的细节，可能会引发一些悬空引用的问题。让我们通过一系列的代码示例来理解这个问题。

示例 1: 直接使用 `ranged-for` 循环

#include <vector>
#include <iostream>
struct S {std::vector<int> data{1, 2, 3, 4, 5};const auto &get_data() const { return data; }
};
S get_s() { return S{}; }
int main() {for (const auto &v : get_s().get_data()) {std::cout << v;}
}

分析：

get_s() 返回了一个临时对象，get_data() 返回了一个对其内部 data 的引用。
在 ranged-for 循环中，const auto &v 试图引用 get_s() 返回的临时对象的 data 向量。这导致了一个 悬空引用，因为 get_s() 返回的临时对象在 ranged-for 循环执行完毕后已经被销毁了。

结果：

这段代码会导致未定义行为 (Undefined Behavior)，因为 v 是一个悬空引用。

示例 2: 显示的迭代器使用

#include <vector>
#include <iostream>
struct S {std::vector<int> data{1, 2, 3, 4, 5};const auto &get_data() const { return data; }
};
S get_s() { return S{}; }
int main() {{auto &&__range = get_s().get_data();auto __begin = begin(__range);auto __end = end(__range);for ( ; __begin != __end; ++__begin ) {const auto &v = *__begin;std::cout << v;}}
}

分析：

这个代码手动获取了 get_data() 返回的引用，并使用标准的 begin() 和 end() 函数进行迭代。
这段代码依然会遇到同样的问题：__range 是对临时对象的引用，临时对象在整个代码块结束时会被销毁。

结果：

__begin 和 __end 迭代器依然指向已经被销毁的临时对象，导致程序的行为未定义。

示例 3: 防止悬空引用 - 使用局部变量

#include <vector>
#include <iostream>
struct S {std::vector<int> data{1, 2, 3, 4, 5};const auto &get_data() const { return data; }
};
S get_s() { return S{}; }
int main() {{const auto s = get_s(); // 初始化局部变量 sauto &&__range = s.get_data(); // 使用 s 的引用，避免悬空引用auto __begin = begin(__range);auto __end = end(__range);for ( ; __begin != __end; ++__begin ) {const auto &v = *__begin;std::cout << v;}}
}

分析：

通过将临时对象 get_s() 存储到局部变量 s 中，我们延长了 s 的生命周期，直到当前作用域结束。
get_data() 返回的引用现在是对 s.data 的引用，s 是一个有效的局部变量，生命周期足够长，ranged-for 循环可以正常工作。

结果：

这段代码将正确打印 1 2 3 4 5。

C++20 新特性：在 `for` 循环中使用初始化语句

C++20 引入了 for 循环的初始化语句，它使得我们能够在循环开始之前初始化变量，从而避免悬空引用问题。这样我们可以确保循环的范围始终是有效的。

#include <vector>
#include <iostream>
struct S {std::vector<int> data{1, 2, 3, 4, 5};const auto &get_data() const { return data; }
};
S get_s() { return S{}; }
int main() {for (const auto s = get_s(); // 初始化 s，避免悬空引用const auto &v : s.get_data()) {std::cout << v;}
}

分析：

const auto s = get_s() 语句确保了临时对象 get_s() 的生命周期被延长，直到 for 循环结束。
for 循环内的 v 将正确引用 s.get_data()，从而避免了悬空引用问题。

结果：

这段代码会正确打印 1 2 3 4 5。

总结：

悬空引用问题： 在 ranged-for 循环中使用引用时，如果引用指向的对象是临时对象（比如返回值），该对象可能会在循环结束前被销毁，从而导致悬空引用。这个问题常见于引用生命周期延长的场景。
避免悬空引用：
- 使用 局部变量 来存储临时对象，确保其生命周期足够长。
- 在 C++20 中，可以利用 for 循环中的初始化语句来确保引用指向的对象在整个循环中保持有效。

惊讶！

ranged-for 循环会隐式创建变量，并自动管理其生命周期。如果这些变量是引用类型且引用临时对象，可能会导致生命周期问题。因此，要小心使用引用，特别是在处理临时对象时。

`if-init` 语句与变量作用域

在 C++17 中，if 语句的初始化（if-init）允许在 if 和 else 语句块中直接声明和初始化一个变量。这使得代码更加简洁，但同时也带来了作用域和潜在的变量覆盖问题，尤其是在使用 else 块时。

代码分析与警告

1. 使用 `if-init` 语句时的潜在警告

int get_val();
double get_other_val();
int main() {if (const auto x = get_val(); x > 5) {// do something with x} else if (const auto x = get_other_val(); x < 5) {// do something else with x}
}

问题：

这段代码在编译时可能会触发警告，提示 x 在 else if 分支中“遮蔽”了前面 if 中的 x 变量。这是因为 x 在 if 和 else if 语句块中有相同的名字，虽然它们作用域上不同，但在某些情况下，编译器可能会产生作用域相关的警告。
警告内容：
x shadows previous declaration of x（x 遮蔽了之前声明的 x）{这个地方我}
这个警告cmake 要开启

add_compile_options(-Wall -Wextra -Wshadow -Werror)

2. 作用域问题 - 不同代码块中的 `x`

{const auto x = get_val();if (x > 5) {// do something with x} else if (const auto x = get_other_val(); x < 5) {// do something else with x}
}

分析：

这里的 x 是在外部作用域内定义的，并且 else if 中的 x 是一个新的局部变量。这两个 x 变量虽然作用域不同，但会在同一个代码块内看到，因此仍然有可能造成混淆。
结果：
else if 块中声明的 x 会隐藏外部作用域的 x，可能会导致一些编译器的警告，或者开发者在理解代码时产生误解。

3. `else` 块中的 `x` 遮蔽问题

{const auto x = get_val();if (x > 5) {// do something with x} else {const auto x = get_other_val(); // shadowingif (x < 5) {// do something else with x}}
}

分析：

在 else 语句块中，x 被重新声明并初始化，覆盖了外部作用域的 x。这就是典型的 变量遮蔽 问题。虽然这是合法的，但会让代码的意图变得不那么清晰，容易导致混乱。

结果：

如果我们在此代码中使用相同的名字 x，则会发生遮蔽。编译器可能会给出警告或错误，告诉你 x 被重新声明和初始化，影响了代码的清晰度。

惊讶！

if-init 语句对于 else 块也是可见的。 当在 if 或 else if 中初始化变量时，变量的作用域是从初始化开始直到该语句块结束，这意味着在 else 块中的初始化也会影响外部的作用域。尽管这通常不会引发错误，但它可能导致意外的变量遮蔽（如上面的代码示例所示）。

总结：

变量作用域：
- if-init 语句会在 if 或 else if 的作用域内创建变量。这意味着在这些语句内部声明的变量只会在它们所在的分支中有效。
- 如果同名的变量在不同的分支中被重新声明，可能会导致 变量遮蔽 问题。
变量遮蔽：
- 在 if-else 语句中，else 块的变量初始化会隐藏外部作用域的同名变量，这可能导致逻辑混淆和潜在的编译警告。
警告和错误：
- 编译器可能会发出警告，指出变量 x 在不同作用域中的重复声明，尤其是在 else 或 else if 块中声明新变量时。
  总之，在使用 if-init 时，务必小心变量的作用域和名称，避免不必要的遮蔽，确保代码清晰且易于维护。

在这段代码中，使用了返回值优化 (RVO)，这意味着编译器会自动优化返回值的构造，避免额外的拷贝或移动构造函数的调用。具体来说，返回值优化 (RVO) 是一个编译器优化，它避免了返回临时对象时的拷贝或移动构造函数的调用，从而提升性能。

解释代码：

构造函数和析构函数的输出：
- S() 是默认构造函数，它会在对象创建时被调用。
- ~S() 是析构函数，它会在对象生命周期结束时被调用。
- S(const S&) 是拷贝构造函数。
- S(S&&) 是移动构造函数。
- operator=(const S&) 和 operator=(S&&) 分别是拷贝和移动赋值运算符。
函数 get_S()：
- get_S() 函数返回一个临时的 S 对象。通常返回一个临时对象时，会触发一个拷贝构造或移动构造。但因为启用了 RVO（或者编译器支持它），它会避免这些额外的构造函数调用。

1. `get_S()` 直接返回临时对象：

S get_S() {return {};
}

这里，返回一个临时对象 S{}。
在启用 RVO 的情况下，编译器会直接将该对象构造在调用者的变量上，而不是进行拷贝或移动，因此不会调用拷贝或移动构造函数。
输出是：

S()
~S()

只会调用默认构造函数和析构函数，说明没有触发拷贝构造或移动构造。

2. `get_other_S()` 调用 `get_S()`：

S get_other_S() { return get_S(); }

get_other_S() 返回 get_S() 的返回值，即返回一个临时 S 对象。
在这个例子中，RVO 可以被应用于 get_S() 的返回，但因为有两个函数调用（get_S() 调用 get_other_S()），编译器通常会应用 返回值优化，避免拷贝和移动。

3. 在 `main()` 中使用 `get_other_S()`：

S s = get_other_S();

由于 get_other_S() 返回一个临时 S 对象，且编译器支持 RVO，所以此时没有触发拷贝构造或移动构造。
由于启用了 RVO，该临时对象直接构造在变量 s 上，因此没有额外的构造函数调用。

输出：

S()
~S()

总结：

RVO（返回值优化）是一个非常强大的优化，它避免了临时对象的拷贝或移动，提升了性能。在 C++17 及更高版本中，返回值优化（RVO）通常是编译器的标准行为，但也可以依赖于编译器的实现。

Subobjects in C++

在 C++ 中，subobjects（子对象）是一个对象的成员变量，结构体成员，或者通过类构造出来的其他对象。理解这些子对象的生命周期和构造过程对性能优化和正确的资源管理非常重要，特别是在涉及拷贝、移动和销毁时。

解释代码和输出

代码解析

#include <cstdio>
struct S {S() { puts("S()"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
struct Holder { S s; // 子对象 s int i; // 整型成员 i
};
Holder get_Holder() { return {}; } // 返回一个 Holder 对象
S get_S() {S s = get_Holder().s; // 从 get_Holder() 返回的 Holder 对象中获取 s（注意这是一个 r-value）return s; // 返回 s，RVO (Return Value Optimization) 可能会优化这个返回
}
int main() {S s = get_S();  // 调用 get_S，接收返回的 S 对象
}

输出解释

第一步： get_S() 被调用。
- 在 get_S() 中，get_Holder() 被调用，返回一个 Holder 对象。
- 在 get_Holder() 中，构造 Holder 对象时，首先会调用 S 的默认构造函数，打印 "S()"。
第二步： 在 get_S() 中，get_Holder().s 触发了 S 的移动构造函数。
- get_Holder().s 是一个临时对象（r-value），因此会调用 S(S&&) 移动构造函数，并打印 "S(S&&)"。
- 由于 get_Holder().s 是局部临时变量，当其离开作用域时，会触发析构函数，打印 "~S()"。
第三步： S s = get_S(); 语句将返回的 S 对象赋值给 s。
- 如果启用了 RVO（返回值优化），get_S() 中的返回语句不会导致拷贝或移动构造。实际操作是直接将返回的对象构造到 s 中，因此不会有额外的拷贝或移动构造。
- 然后，s 的生命周期结束时会触发析构函数，打印 "~S()"。

打印输出

S()
S(S&&)
~S()
~S()

Surprise!

自动发生的移动：C++ 编译器会自动在需要时移动临时对象（r-value），你无需显式帮助它。这是 C++ 的“移动语义”。
RVO（返回值优化）：返回值优化会消除从函数返回时的临时对象拷贝。编译器会直接将返回的对象构造到接收变量的位置。这是为了避免不必要的资源复制，提高程序的性能。

总结

S s = get_S(); 中的 s 是通过返回值优化（RVO）直接从 get_S() 中构造的，因此没有额外的拷贝构造。
get_Holder().s 是一个临时对象，它触发了 S 的移动构造，并在离开作用域时析构。
编译器优化（如 RVO）可以显著减少对象创建和销毁的次数，这对性能有积极影响。

Structured Bindings in C++

在 C++17 引入了结构化绑定（Structured Bindings），它允许我们将多个值（例如元组、结构体成员）解构并绑定到多个变量上。这使得代码更简洁，更易于理解，特别是在处理复杂数据结构时。
然而，结构化绑定会涉及到一些细节，特别是在对象的拷贝和移动时，可能会导致一些不太直观的结果。

代码解析与输出

代码 1：使用结构化绑定

#include <cstdio>
struct S {S() { puts("S()"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
struct Holder { S s; // 结构体成员int i;
};
Holder get_Holder() { return {}; }
S get_S() {auto [s, i] = get_Holder();  // 结构化绑定return s;  // 返回 s
}
int main() {S s = get_S();  // 调用 get_S()，接收返回的 S 对象
}

输出解释

第一步： 调用 get_S()，该函数内部调用 get_Holder()，返回一个 Holder 对象。
- 在 get_Holder() 中，Holder 对象的构造函数被调用，构造 S 时调用 S() 构造函数，并打印 "S()"。
第二步： 结构化绑定将 get_Holder() 返回的 Holder 对象解构，赋值给 s 和 i。
- auto [s, i] = get_Holder(); 将 Holder 中的 S 和 int 成员绑定到 s 和 i 变量。
- 由于 s 是通过拷贝初始化的，因此会调用 S 的拷贝构造函数，并打印 "S(const S &)"。
第三步： return s; 语句返回 s。
- 由于 s 是一个局部变量，在返回时需要执行拷贝或移动构造。因为没有启用 RVO（返回值优化），所以会调用拷贝构造函数，打印 "S(const S &)"。
第四步： 在 main 函数中，S s = get_S(); 语句接收返回的 S 对象。
- 再次调用拷贝构造函数，并打印 "S(const S &)"。
- 最后，s 的析构函数会被调用，打印 "~S()"。

打印输出

S()
S(const S &)
S(const S &)
~S()
~S()

代码 2：避免结构化绑定中的引用

#include <cstdio>
struct S {S() { puts("S()"); }S(const S &) noexcept { puts("S(const S &)"); }S(S &&) noexcept { puts("S(S&&)"); }S &operator=(const S &) { puts("operator=(const S&)"); return *this; }S &operator=(S &&) { puts("operator=(S&&)"); return *this; }~S() { puts("~S()"); }
};
struct Holder { S s; int i; 
};
Holder get_Holder() { return {}; }
S get_S() {auto e = get_Holder(); // 通过临时对象初始化 eauto &s = e.s;         // 绑定引用auto &i = e.i;         // 绑定引用return s;              // 返回 s，RVO 不会被应用，因为 s 是引用
}
int main() {S s = get_S();  // 调用 get_S()
}

输出解释

第一步： 调用 get_S()，返回一个 Holder 对象，构造时会调用 S() 构造函数，打印 "S()"。
第二步： auto e = get_Holder(); 创建 Holder 对象 e，在返回 e 后，结构体的成员 e.s 和 e.i 是通过引用绑定到 s 和 i 的。
- auto &s = e.s; 和 auto &i = e.i; 都是绑定到 e 的成员。因此它们不会涉及到拷贝或移动构造。
- 但是，返回的是 s，并且 s 是一个引用，结构化绑定并没有涉及对象的拷贝或移动。
第三步： return s; 语句返回 s，没有启用 RVO，因此会执行拷贝构造，打印 "S(const S &)"。
第四步： 在 main() 中，S s = get_S(); 接收返回的 S 对象。执行拷贝构造，再次打印 "S(const S &)"。

打印输出

S()
S(const S &)
S(const S &)
~S()
~S()

Surprise!

引用与 RVO：结构化绑定会生成隐藏的引用，而引用本身并不是对象，因此在返回引用时，RVO 和自动移动等优化无法应用。这意味着结构化绑定可能导致多余的拷贝构造操作，尤其是在返回引用时。
结构化绑定中的隐式拷贝：当我们使用结构化绑定解构返回的对象时，如果绑定的是引用，那么优化（如 RVO）将无法应用，可能会触发额外的拷贝构造或移动构造。

总结

结构化绑定是一项非常有用的特性，它让我们可以轻松地解构复杂的类型（如元组、结构体）并绑定到变量上。
但是，在某些情况下，使用结构化绑定可能会导致额外的拷贝操作，特别是当绑定的是引用时。
如果希望避免不必要的拷贝构造，可以确保绑定到合适的类型并理解对象的生命周期和移动语义。

Delegating Constructors in C++

C++11 引入了 委托构造函数（Delegating Constructors），允许一个构造函数调用另一个构造函数，而不需要重复代码。通过这种方式，可以更好地管理和简化类的构造逻辑。
但是，委托构造函数也涉及到一些特殊的生命周期和析构问题，特别是在构造过程中抛出异常时。

代码解析与输出

代码 1：简单的构造与析构

#include <cstdio>
struct S {int i{};S() = default;S(int i_) : i{i_} {}~S() { puts("~S()"); }
};
int main() {try {S s{1};  // 构造 S} catch (...) {}
}

输出解释

第一步： 在 main 函数中创建一个对象 S s{1};。
- 调用 S(int) 构造函数，将 i 初始化为 1。
- 由于构造函数没有抛出异常，构造成功，S 对象的生命周期开始。
第二步： main 函数结束时，S 对象 s 的析构函数被调用，输出 "~S()"。

打印输出

~S()

代码 2：构造函数抛出异常

#include <cstdio>
struct S {int i{};S() = default;S(int i_) : i{i_} { throw 1; }  // 构造时抛出异常~S() { puts("~S()"); }
};
int main() {try {S s{1};  // 构造 S} catch (...) {}
}

输出解释

第一步： 在 main 函数中创建对象 S s{1}; 时，调用 S(int) 构造函数。
- 构造函数抛出异常，导致构造失败。
第二步： 由于构造函数抛出异常，S 对象并未成功构造，因此不会调用析构函数。

打印输出

（没有输出）

代码 3：委托构造函数与异常

#include <cstdio>
struct S {int i{};S() = default;S(int i_) : S{}  // 委托构造函数，调用默认构造函数{ i = i_; throw 1;  // 构造时抛出异常}~S() { puts("~S()"); }
};
int main() {try {S s{1};  // 构造 S} catch (...) {}
}

输出解释

第一步： 在 main 函数中，S s{1}; 调用 S(int) 构造函数。
- S(int) 构造函数通过委托调用 S() 默认构造函数。
- S() 默认构造函数成功执行，但之后 S(int) 构造函数继续执行，抛出异常。
第二步： 由于异常抛出，S 对象构造失败，S 对象并未成功创建，且析构函数不会被调用。 (这个地方说的不对构造成功了，会调用析构)

打印输出

~S()

代码 4：委托构造函数的析构

#include <cstdio>
struct S {int i{};S() = default;S(int i_) : S{}  // 委托构造函数，调用默认构造函数{ i = i_; throw 1;  // 抛出异常}~S() { puts("~S()"); }
};
int main() {try {S s{1};  // 构造 S} catch (...) {}
}

输出解释

第一步： S(int) 构造函数通过委托调用 S() 默认构造函数。
- S() 构造函数成功执行后，S(int) 构造函数继续执行并抛出异常。
第二步： 尽管构造函数抛出了异常，但在委托构造函数完成之前，S 对象的生命周期尚未开始。因此，S 对象的析构函数仍然会被调用。

打印输出

~S()

代码 5：带有委托的资源管理

struct S {int *ptr{nullptr};int *ptr2{nullptr};S() = default;S(int val1, int val2) : S{} {  // 委托构造函数ptr = new int(val1);ptr2 = new int(val2);}~S() { delete ptr; delete ptr2; }  // 资源释放
};

输出解释

第一步： S(int, int) 构造函数通过委托调用 S() 默认构造函数。此时，ptr 和 ptr2 都被初始化为 nullptr。
第二步： 在 S(int, int) 构造函数中，动态分配了 ptr 和 ptr2 指针的内存。
第三步： 在析构函数中，释放了 ptr 和 ptr2 指向的内存。如果 ptr 或 ptr2 是 nullptr，delete nullptr 也是有效的，不会引发错误。

总结：

委托构造函数：允许一个构造函数调用另一个构造函数，这对于避免重复代码非常有用。
析构函数的调用：即使在构造函数中抛出异常，如果委托构造函数已经完成，析构函数仍然会被调用。
资源管理：当使用动态内存时，确保析构函数正确地释放资源，并且委托构造函数正确地完成资源分配。

Surprise!

对象的生命周期开始：一个对象的生命周期从其构造函数完全成功执行后开始。在委托构造函数的情况下，如果抛出了异常，委托构造的完整性会中断，但析构函数仍然会被调用，因为对象在委托构造之前的构造已开始。

C++ 中的临时对象生命周期和引用问题

在 C++ 中，临时对象的生命周期（如返回值、临时变量等）管理是一个重要的话题。若处理不当，可能会导致内存访问错误或其他未定义行为。以下是对你提供的几个例子的详细解读。

1. 避免生命周期问题：返回临时对象的引用

不推荐的写法：

auto get_first() {auto [first, second] = get_pair();  // 不好的做法return first;  // 返回一个对临时对象的引用
}

问题分析：

这段代码的问题在于，get_first() 返回的是 first 的引用，而 first 是 get_pair() 返回的临时对象的成员。
get_pair() 返回的是一个临时的 pair 对象，该对象在表达式结束后会被销毁。
因此，返回 first 的引用会导致悬空引用，访问这个引用会导致未定义行为，比如程序崩溃。

2. 使用 `&&` 强制要求所有结构化绑定为右值引用

在使用结构化绑定时，临时对象的生命周期问题可能更加微妙。为了更好地控制临时对象的生命周期，可以考虑使用右值引用（&&）进行绑定。

例子：

auto get_sum() {// 使用 const & 能很好地利用生命周期延长规则，// 同时也让代码更清晰地表明我们在处理的是临时对象const auto &[first, second] = get_pair();return first + second;
}

问题分析：

在 get_sum() 中，使用结构化绑定来获取 get_pair() 返回值的 first 和 second 成员。
这里使用的是 const auto&，即常量引用，这样 first 和 second 就是对 get_pair() 返回的临时对象的引用。
使用常量引用时，C++ 会延长临时对象的生命周期，直到引用离开作用域。这确保了在引用存在的期间，临时对象不会被销毁。

为什么使用右值引用（`&&`）？

在某些情况下，使用右值引用（&&）可以帮助更明确地控制临时对象的生命周期：

auto get_sum() {// 如果你希望明确地处理右值，或者避免不必要的生命周期延长：auto &&[first, second] = get_pair();  // 使用右值引用return first + second;
}

分析：

使用 auto&& 明确地告诉编译器 first 和 second 是右值引用，这有助于避免临时对象生命周期的延长。
这种做法可以让你显式地管理右值，避免不必要的复制，甚至可以利用移动语义进行优化。

结论：

避免返回临时对象的引用，尤其是在结构化绑定和返回值时。最好的做法是返回值而非引用，这样可以避免生命周期问题。
结构化绑定（如 auto&&）是一个强大的工具，但你需要了解它如何影响临时对象的生命周期。使用 const auto& 来确保临时对象生命周期被正确延长。
始终记住，右值引用 (&&) 提供了更细粒度的控制，可以避免不必要的生命周期延长，特别是在处理临时对象时。

理解 C++ 中的工具使用和潜在问题

在这部分内容中，主要涉及了几个重要的 C++ 编程概念，如错误检测、生命周期管理、**constexpr**的使用等。这些问题通常涉及潜在的内存管理问题、未定义行为、以及编译时错误，都是我们在编程中需要特别注意的。

1. 警告所有的事情（Warn All The Things）

为了避免程序出现潜在的错误，启用编译器的警告并确保所有潜在问题都会被报告是非常重要的。通过启用警告选项，可以帮助我们及时发现问题。例如：

-Wall 或 -Wshadow：这些警告帮助我们识别变量遮蔽（即，局部变量遮蔽了外部变量的名字），以及一些可能引发错误的行为。
使用 MSVC 和 Clang-Tidy 等工具也能帮助捕获常见错误，如数组到指针的转换等。

2. 使用 Sanitizers 检查潜在问题

在开发过程中，某些错误（如内存越界、悬空指针等）可能不会直接导致编译错误，但会在运行时造成崩溃。为了尽早发现这些问题，可以使用Sanitizers工具。

Sanitizers 是一种用于捕获内存错误、线程错误、未初始化变量等问题的工具。使用这些工具可以帮助我们在程序运行时发现很多潜在的崩溃或未定义行为。
例如，通过启用 -fsanitize=address 选项，我们可以检测内存错误；使用 -fsanitize=undefined 来捕获未定义行为。

3. 小心使用 `initializer_list<>`

initializer_list 是一种非常方便的 C++ 特性，它允许我们使用初始化列表来创建容器或其他对象。然而，在使用它时要非常小心，特别是它的构造函数。

initializer_list 与 initializer_list<>：需要理解这两者的区别。initializer_list<> 通常用于传递一组固定元素的列表，但它并不是万能的，特别是在处理非简单类型时。
使用 initializer_list 的问题：它应该只用于简单类型或字面量类型，以避免潜在的性能问题或类型安全问题。

4. `constexpr` 的使用

constexpr 是 C++11 引入的一个关键字，它用于表示某些值在编译时就已知，通常与常量表达式、编译时计算相关。它可以帮助我们更好地利用编译器的优化，但也有一些注意点。

示例：返回悬空引用（`dangling reference`）

int& get_val() {int i{};  // 局部变量return i;  // 返回局部变量的引用，悬空引用
}

问题分析：

这里的代码会导致一个悬空引用，因为i 是局部变量，在函数结束时会被销毁。返回它的引用会导致未定义行为。
编译时并不会报错，但运行时会导致访问非法内存。

修复：

constexpr int get_val() {return 42;  // 直接返回常量，不会有悬空引用问题
}

注意：

constexpr 函数要求编译器在编译时求值，这意味着必须遵守一些严格的规则，比如不能返回悬空引用。

5. `constexpr` 中的未定义行为

C++ 的 constexpr 并不能允许存在未定义行为。即使是编译时常量，也要求没有悬空指针、内存越界等问题。

示例：

constexpr int& get_val() {int i{};  // 局部变量return i;  // 返回悬空引用
}

在 constexpr 中，这样的代码会导致编译时错误，因为编译器无法验证 i 的生命周期是否足够长。

6. 使用 `std::string_view` 注意生命周期

std::string_view 是一种轻量级的字符串视图，它并不管理所指向字符串的内存。如果指向的字符串已经销毁，std::string_view 会变成悬空引用，导致未定义行为。

示例：

std::string_view get_value() {const char str[] = "Hello World";  // 局部数组return str;  // 返回悬空指针
}

问题分析：

在这种情况下，get_value() 返回一个指向局部变量 str 的 string_view，但 str 是局部数组，函数返回后该数组就被销毁，因此 string_view 会变成悬空引用。
这种代码会导致未定义行为，程序可能崩溃。

解决方案：

constexpr std::string_view get_value() {static const char str[] = "Hello World";  // 使用静态存储期return str;  // 现在不会有悬空引用问题
}

使用 static 关键字可以确保字符串的生命周期在函数调用结束后仍然有效。

总结

在 C++ 编程中，使用一些工具和技术来捕获潜在的错误是非常重要的，特别是在处理临时对象、常量表达式和指针时，可能会出现一些细微的生命周期管理问题。利用编译器的警告、Sanitizers 和 constexpr 等特性，可以帮助我们避免许多常见的错误。

查看全文

http://www.xdnf.cn/news/15010.html

深度学习5(深层神经网络 + 参数和超参数)

C++ 网络编程(15) 利用asio协程搭建异步服务器

从数据洞察到设计创新：UI前端如何利用数字孪生提升用户体验？

浏览器与服务器的交互

dify 1.5.1版本全面解析——知识库索引、动态参数及结构化输出插件全新登场

STM32的 syscalls.c 和 sysmem.c

《C++初阶之类和对象》【经典案例：日期类】

RESTful API 安装使用教程

黑马python（二十五）

Spring Boot + 本地部署大模型实现：优化与性能提升

基于Linux的Spark本地模式环境搭建实验指南

【github】想fork的项目变为私有副本

项目介绍：LangGPT

Android View的绘制原理详解

使用reactor-rabbitmq库监听Rabbitmq

Python 量化交易安装使用教程

opencv的颜色通道问题 rgb bgr

如何查看自己电脑的CUDA版本？

【深度解析】Seedance 1.0：重新定义 AI 视频生成的工业级标准

《Java修仙传：从凡胎到码帝》第三章：缩进之劫与函数峰试炼

python脚本编程：使用BeautifulSoup爬虫库获取热门单机游戏排行榜

PHP从字符串到数值的类型转换

三、jenkins使用tomcat部署项目

服务器间接口安全问题的全面分析

模拟热血三国内城安置建筑物

【wps】 excel 删除重复项

1. 什么是对象（Object）？

2. int 与包含 int 的结构体有什么不同？

3. 统一初始化语法（Uniform Initialization Syntax）

4. 静态断言与类型特征（Static Assertions and Type Traits）

总结

标准是怎么说的？

这意味着什么？

那么，什么是对象类型？

对象类型的示例：

不是对象类型的示例：

总结：

对象生命周期

1. 生命周期开始

例如：

2. 生命周期结束

例如：

3. 总结

Basic Object Lifetime（基本对象生命周期）

代码 1:

分析：

代码 2:

分析：

代码 3:

分析：

代码 4:

分析：

总结：

问题分析：

代码：

分析：

实际输出：

警告：

总结：

注意：

问题背景：

具体分析：

代码：

分析：

编译器的行为：

Clang/GCC 的警告：

警告的含义：

如何修复：

总结：

问题解析：

代码示例 1：

输出：

为什么这个是允许的？

代码示例 2：

输出：

解释：

代码示例 3：

输出：

为什么输出是未知的？

警告信息：

总结：

如何修复：

代码分析：std::string_view 和局部数组的行为

代码示例：

这里发生了什么？

预期的行为：

没有警告：

在实践中会发生什么？

结论：

如何修复这个问题：

容器和类型析构：一个详细分析

代码分析：

主要操作：

预期的输出：

意外之处：

总结：

实践建议：

emplace_back 和 std::vector 容器使用分析

案例 1：使用 emplace_back 传递一个已经构造的对象（错误用法）

发生了什么？

预期输出：

案例 2：正确使用 emplace_back 传递一个构造参数

发生了什么？

预期输出：

案例 3：使用 emplace_back 并传递默认构造函数

发生了什么？

2. `int` 与包含 `int` 的结构体有什么不同？

代码分析：`std::string_view` 和局部数组的行为

`emplace_back` 和 `std::vector` 容器使用分析

案例 1：使用 `emplace_back` 传递一个已经构造的对象（错误用法）

案例 2：正确使用 `emplace_back` 传递一个构造参数

案例 3：使用 `emplace_back` 并传递默认构造函数

案例 4：`emplace_back` 传递数组的引用

理解 `std::initializer_list` 和动态内存分配

`std::array` 和内存分配

分析 `std::array` 初始化：

1. `std::array` 类型推导：

3. 更复杂的 `std::array<std::string, 2>`：

4. `std::array` 的效率：

Ranged-for Loops 和引用生命周期

示例 1: 直接使用 `ranged-for` 循环

C++20 新特性：在 `for` 循环中使用初始化语句

`if-init` 语句与变量作用域

1. 使用 `if-init` 语句时的潜在警告

2. 作用域问题 - 不同代码块中的 `x`

3. `else` 块中的 `x` 遮蔽问题

1. `get_S()` 直接返回临时对象：

2. `get_other_S()` 调用 `get_S()`：

3. 在 `main()` 中使用 `get_other_S()`：