在上一篇文章中，我们聊到了从 C# 到 C++ 的思维转变，核心在于内存管理。你已经知道了 C++ 赋予了你直接掌控内存的权力，以及随之而来的责任。今天，我们将深入探讨 C++ 的核心特性：指针，它既是 C++ 强大的基石，也是新手最容易犯错的“陷阱”。同时，我们还会对比 C# 和 C++ 在异常处理和模板/泛型上的不同哲学。

---

引言：指针——力量与风险的博弈

如果你在 C# 里写过 unsafe 代码块，或许对指针有一点点印象。但在 C++ 里，指针是无处不在的。它允许你直接操作内存地址，这带来了极高的性能，但也让你的代码变得脆弱。可以说，理解指针，就是理解 C++ 力量的来源，以及如何驾驭这股力量，而不是被它反噬。

---

指针与安全：从托管安全到非托管风险

C# 的安全性

C# 的设计哲学是类型安全（Type Safety）和内存安全（Memory Safety）。在日常开发中，你几乎不会遇到野指针或内存泄漏。这是因为：

1. 托管内存：GC 自动管理堆内存，无需手动释放。

2. 类型安全：C# 严格执行类型规则，你不能把一个 int 指针当作一个 string 指针来用（除非通过 unsafe 和显式转换）。

正是这些安全措施，让 C# 开发者可以专注于业务逻辑，而不必担心底层内存错误。

C++ 的指针操作与安全问题

C++ 的强大之处在于它对内存的直接访问能力，但这把双刃剑也带来了严重的安全问题。

1. 悬空指针（Dangling Pointer）：当一个指针指向的内存已经被释放，但指针本身仍然存在时，它就成了“悬空指针”。如果你试图通过它访问内存，就会导致未定义行为，通常表现为程序崩溃或数据损坏。

   C++

   int* ptr = new int(10); // 在堆上分配一个 int
   delete ptr;            // 释放内存
   // 此时 ptr 成为悬空指针
   *ptr = 20;             // 尝试访问已释放的内存，危险！
   
   

2. 缓冲区溢出（Buffer Overflow）：这是另一个经典的安全问题。当你试图向一个数组写入超过其边界的数据时，就会覆盖相邻的内存区域，从而导致各种不可预测的错误。

   C++

   char buffer[10];
   strcpy(buffer, "This is a very long string"); // 复制一个超过 10 字节的字符串，危险！
   
   

这些问题在 C# 的托管环境中几乎不可能发生。在 C++ 里，它们是真实存在的威胁。

智能指针（Smart Pointers）：驾驭 C++ 的缰绳

为了解决上述问题，现代 C++ 引入了智能指针（Smart Pointers），它们是 C++ RAII（资源获取即初始化）原则的典范应用。智能指针可以像普通指针一样使用，但它们在封装对象的同时，也自动管理其生命周期。

• std::unique_ptr：独占所有权。它确保一个对象只能被一个指针拥有。当 unique_ptr 离开作用域时，它会自动 delete 所指向的对象。这非常适合管理生命周期明确的堆对象。

• std::shared_ptr：共享所有权。它通过引用计数来跟踪有多少个指针共享同一个对象。只有当所有 shared_ptr 都被销毁时，对象才会被释放。这在多个地方需要共同拥有一个对象时非常有用。

Unreal 引擎也提供了自己的智能指针，如 TUniquePtr 和 TSharedPtr，它们与标准库的智能指针类似，但在某些方面提供了额外的功能和性能优化，并且能更好地与引擎的容器和系统集成。在 Unreal 中，你应该尽可能使用这些智能指针来管理非 UObject 的堆内存，而不是原始指针。

---

异常处理：从 try-catch 到 check() / ensure()

C# 的 try-catch 机制

在 C# 中，我们习惯于用 try-catch 块来优雅地处理运行时错误。比如，当我们尝试解析一个无效的字符串为整数时：

C#

try
{
    int number = int.Parse("abc");
}
catch (FormatException ex)
{
    Debug.LogError("Error parsing string: " + ex.Message);
}

这种机制非常灵活，它允许你在程序的任何地方捕获并处理异常，而不会导致程序崩溃。

Unreal C++ 的错误处理：禁用异常

Unreal C++ 默认禁用了标准异常处理（C++ Exceptions）。为什么？主要出于以下考虑：

1. 性能开销：异常处理在运行时会产生额外的性能开销。在对性能要求极高的游戏引擎中，这是不可接受的。

2. 跨平台兼容性：C++ 异常在不同的编译器和操作系统上可能存在差异，这会增加引擎跨平台开发的难度。

3. 确定性：异常会导致非线性的代码流程，这会使调试变得复杂。Unreal 更倾向于可预测的、线性的执行流程。

那么，Unreal 是如何处理错误的呢？

• 断言宏（Assertion Macros）：Unreal 提供了 check() 和 ensure() 两个宏。它们只在开发和调试版本中生效。

  • check()：如果其内的条件为假，程序会立即断言并崩溃。这适用于那些“绝对不可能发生”的情况，比如一个空指针，因为它能让你在开发阶段尽早发现 bug。

  • ensure()：与 check() 类似，但它不会立即崩溃，而是会打印一个错误日志并返回一个布尔值。这适用于你希望在错误发生时记录日志，但又不想立即终止程序的情况。

• 返回错误码：在没有异常处理时，函数通常会返回一个布尔值（成功/失败）或一个枚举类型的错误码，让调用者来决定如何处理。这是一种更传统的、命令式的错误处理方式。

这种转变要求你从“发生错误时捕获”的思维，转变为“预防错误发生”的思维。在 Unreal C++ 中，你必须更主动地检查函数调用的返回值，并用断言来提前捕获那些不该发生的错误。

---

模板与泛型：编译期实例化与运行时类型擦除

C# 的泛型

C# 的泛型（Generics）在运行时实现。当你声明 List<int> 和 List<string> 时，它们在编译后会生成相同的中间语言（IL），只是在运行时，JIT 编译器会为不同的类型生成对应的本地代码。这种方式被称为类型擦除（Type Erasure），它使得泛型代码量更小，编译速度更快。

但这种运行时实现也限制了泛型的能力，比如你无法在泛型参数上进行复杂的算术运算。

C++ 的模板

C++ 的模板（Templates）则是一种完全不同的哲学。它在编译期实例化（Compile-time Instantiation）。

当你使用 std::vector<int> 和 std::vector<double> 时，编译器会为这两种类型各自生成一份独立的、完整的代码。这使得模板具有极大的灵活性，你可以对模板参数进行各种编译期操作，甚至进行模板元编程（Template Metaprogramming）——在编译期进行类型计算，这是一种非常高级的编程技巧。

C++

template <typename T>
T Add(T a, T b)
{
    return a + b;
}

// 编译器会为每种类型生成一份独立的函数
int sum_int = Add<int>(1, 2);
double sum_double = Add<double>(1.0, 2.0);

Unreal 引擎大量使用了模板，比如你经常会遇到的 TArray<T>、TMap<Key, Value> 等容器。掌握模板，是理解 Unreal 容器和数据结构工作原理的关键。

---

核心总结：迈向真正的 C++ 开发者

通过本篇文章，你应该意识到，从 C# 到 C++ 的转变，不仅是语言层面的，更是编程哲学层面的。

• 指针：你需要从习惯于安全的引用，转变为主动管理内存的思考。智能指针是你的新工具，而原始指针则是你必须警惕的危险。

• 错误处理：你需要从习惯于 try-catch，转变为主动预防和断言的思考。check() 和 ensure() 是你最忠实的开发助手。

• 模板：你需要从理解运行时泛型，转变为理解编译期模板，这为你开启了更强大的代码复用和元编程世界。

这些特性共同构成了 C++ 的核心优势，也是 Unreal 引擎能够实现高性能和高灵活性的基石。掌握它们，你就掌握了从一个 C# 开发者，向一个真正的 C++ 开发者转变的关键。

在下一篇文章中，我们将讨论继承、多态、编译模型，并对比两个引擎的标准库和容器。这将帮助你理解 Unreal 庞大代码库的组织方式，并学会如何正确地使用它。