C#到C++迁移要点1：从托管世界到非托管战场

从 Unity C# 到 Unreal C++，这可不是一个简单的语言切换，而是一次完整的思维模式大迁移。它不仅仅是换个语法那么简单，而是要重新理解类型、内存、生命周期，甚至是你每天写代码的编译流程。

---

引言：从托管世界到非托管战场

在 Unity 的世界里，我们习惯了 C# 带来的舒适和安全。C# 是一种高级、托管的语言。这个“托管”是什么意思？简单来说，就是有一个强大的 **.NET 运行时（Runtime）**在背后默默地为你打理一切，包括内存分配、垃圾回收，甚至一些底层的性能优化。你只需要专注于游戏逻辑，而不用担心那些烦人的内存泄漏、悬空指针。

然而，Unreal 的 C++ 则是另一个极端。它是一门底层、非托管的语言。它赋予了你直接操作内存、控制底层硬件的终极权力。这种权力带来了无与伦比的性能和灵活性，但也附带着巨大的责任。在这里，你就是内存的国王，每分配一块内存，就必须亲手把它释放掉，否则就会引发灾难。

这种本质上的差异，决定了我们在写代码时的每一步思考都将有所不同。

---

语法结构与文件组织：C# 的“一体化”与 C++ 的“分而治之”

C# 的单文件模式

在 C# 中，我们习惯将一个类的所有定义和实现都放在同一个 .cs 文件里。比如，一个简单的 Player.cs 文件，它可能长这样：

C#

using UnityEngine;

public class Player : MonoBehaviour
{
    public float moveSpeed = 5f;

    void Update()
    {
        // 移动逻辑
        transform.Translate(Vector3.forward * moveSpeed * Time.deltaTime);
    }
}

这种模式非常直观，一个文件就是一个类，清晰明了，尤其适合小型到中型项目。编译器会一次性处理这个文件中的所有代码，然后生成对应的中间语言（IL），最后由 .NET 运行时在执行时进行即时编译（JIT）。

C++ 的头文件/源文件模式

C++ 的世界则完全不同。为了高效地管理代码和编译，C++ 引入了**头文件（.h 或 .hpp）和源文件（.cpp）**的传统。

• 头文件（.h）：它就像是一个类的“蓝图”或“接口契约”。在这里，你只声明类、函数、变量，告诉编译器这些东西“存在”，但具体怎么实现，我稍后再告诉你。

• 源文件（.cpp）：它是头文件中的“具体实现”。在这里，你为头文件中声明的函数和变量提供定义，编写具体的逻辑代码。

例如，一个简单的 Player 类在 C++ 中可能会被拆分成两个文件：

Player.h

C++

#pragma once // 确保这个头文件只被包含一次

#include "CoreMinimal.h" // 包含 Unreal 核心类型

class Player
{
public:
    Player(); // 构造函数声明
    ~Player(); // 析构函数声明

    void Move(float DeltaTime); // 移动函数声明

private:
    float MoveSpeed; // 变量声明
};

在 Unreal 中，我们通常用 #pragma once 来避免头文件重复包含，它比传统的 #ifndef / #define / #endif 更现代、更简洁。

Player.cpp

C++

#include "Player.h" // 包含头文件，才能使用头文件中声明的内容

Player::Player()
    : MoveSpeed(5.0f) // 初始化列表
{
    // 构造函数实现
}

Player::~Player()
{
    // 析构函数实现
}

void Player::Move(float DeltaTime)
{
    // 移动函数实现
    // ...
}

这种分离有什么好处？

最大的优点在于编译效率。当你在一个 Player.cpp 文件中修改了某个函数的实现时，编译器只需要重新编译这个 Player.cpp 文件。其他依赖 Player.h 的文件（比如 GameMode.cpp）不需要重新编译，因为它们的“接口”没有变化。这在大型项目中可以极大地节省编译时间，让你的迭代效率更高。

宏与预处理

C++ 还有一个非常强大的武器：预处理（Preprocessor）。它在真正的编译开始之前，会对你的代码进行一番“预处理”。我们刚刚看到的 #pragma once 和 #include 就是预处理指令。另一个常见的预处理功能是宏（Macros）。

在 Unreal 引擎中，你会看到大量的宏，比如 UCLASS(), UFUNCTION(), UPROPERTY()。这些宏是 Unreal 的元数据（Metadata）系统基石，它们在预处理阶段被特殊的 **Unreal 头文件工具（UHT）**解析，并生成额外的代码，让引擎能够反射（Reflection）你的 C++ 类，从而在编辑器中显示属性、调用函数等。

UPROPERTY(EditAnywhere)

UFUNCTION(BlueprintCallable)

这些宏看起来有点奇怪，但它们是 Unreal 赋予 C++ 强大编辑器集成能力的秘密武器，是我们 C# 开发者在 Unity 中从未体验过的。

---

类型系统与内存分配：栈与堆的博弈

C# 的值类型与引用类型

在 C# 中，类型被清晰地划分为两类：

• 值类型（Value Types）：比如 int, float, struct。它们的数据直接存储在**栈（Stack）**上。栈是一种“先进后出”的数据结构，内存分配和释放非常快，生命周期由其作用域自动管理。当变量离开作用域时，栈上的内存会自动回收。

• 引用类型（Reference Types）：比如 class, string, Array。它们的数据存储在堆（Heap）上。堆是一块巨大的、自由的内存区域，你可以随时申请和释放。但问题是，堆内存的分配和回收通常比栈慢，而且回收需要通过垃圾回收器（Garbage Collector, GC）来完成。引用类型的变量本身只是一个指向堆上对象的“引用”，或者说是一个指针。

C#

// 栈上分配
int a = 10;
Vector3 position = new Vector3(1, 2, 3); // Vector3 是 struct，所以也在栈上

// 堆上分配
MyClass myObject = new MyClass(); // MyClass 是 class，在堆上分配

C++ 的值对象与指针/引用

C++ 没有 C# 那么清晰的值类型和引用类型概念，但它有类似的设计哲学：

• 值对象（Value Objects）：当你像这样声明一个变量时，它默认是栈上分配的。

C++

// 栈上分配，生命周期由作用域自动管理
int a = 10;
FVector Position(1.0f, 2.0f, 3.0f); // Unreal 的 FVector 是一个 struct

它的生命周期与 C# 的值类型一样，当它所在的函数结束时，它会自动销毁，无需你手动管理。

• 指针与引用（Pointers & References）：这是 C++ 真正强大的地方，也是新手最容易犯错的地方。

  • 指针（Pointer）：它是一个变量，其值是另一个变量的内存地址。你可以用它来“指向”堆上或栈上的对象。它就像一个 C++ 的原始“引用”。

  • 引用（Reference）：它是一个对象的别名，一旦初始化，就不能改变指向。它更像是 C# 的引用，但它不能指向 nullptr，通常更安全。

C++

// 在堆上分配，需要手动管理
Player* MyPlayer = new Player();

// 引用，不能为 nullptr
Player& RefPlayer = *MyPlayer;

需要注意的是，指针本身也是一个值对象，它存储在栈上，但它所指向的那个对象，可以是在堆上或栈上。

---

内存管理：垃圾回收与手动控制

C# 的垃圾回收（GC）

C# 的 GC 是一个强大的幕后英雄。当你使用 new 创建一个引用类型对象时，它会分配在托管堆上。当这个对象不再有任何变量引用它时，GC 会在某个合适的时机自动找到它并回收内存。

这种机制极大地方便了开发者，但并非没有代价。GC 运行需要消耗 CPU 时间，这在游戏循环中被称为 GC Alloc。如果频繁地分配和回收内存，就可能导致 GC 频繁启动，从而引发卡顿（Stuttering）。在 Unity 中，优化 GC Alloc 是性能优化的一个重要课题。

C++ 的手动管理

在传统的 C++ 中，堆内存的管理完全是开发者的责任。

• new 和 delete：当你使用 new 在堆上创建对象时，你必须在适当的时机使用 delete 来释放它。如果你忘记了 delete，就会发生内存泄漏（Memory Leak）。

• RAII（资源获取即初始化）：这是 C++ 的核心设计哲学之一。它提倡将资源的生命周期绑定到一个对象的生命周期上。最经典的例子是智能指针（Smart Pointers）。当你用 std::unique_ptr 或 std::shared_ptr 封装一个在堆上创建的对象时，当智能指针本身离开作用域（在栈上），它会自动调用 delete 释放其所持有的对象。这极大地减少了内存泄漏的风险。

Unreal 的 UObject GC

Unreal 引擎在 C++ 的基础上，构建了一个独特的 UObject 垃圾回收系统。它并不完全取代 C++ 的手动内存管理，而是为所有从 UObject 继承的类提供了一种**引用计数（Reference Counting）**的 GC 机制。

当你有一个 UPROPERTY() 标记的 UObject 指针时，引擎会自动跟踪它。当一个 UObject 不再被任何 UPROPERTY() 指针引用时，它就会被标记为待回收，并在下一次 GC 循环中被销毁。

但是！这个 UObject GC 只对 UObject 有效。如果你在 Unreal C++ 中 new 了一个普通的非 UObject 类，比如一个 std::string 或一个自定义的 struct，你仍然需要手动 delete 它，或者用智能指针管理。

---

核心总结：思维模式的大转变

从 C# 到 C++，最根本的转变在于内存管理。

在 C# 中，你习惯了让 GC 帮你处理一切。但在 C++ 的世界里，你必须成为一个严谨的内存管理者。每一次 new，都意味着一次责任。

而 Unreal 引擎，则是在这个 C++ 的基础上，为你提供了一套半自动化的工具。它通过 UObject GC 减轻了你对游戏对象内存管理的负担，但对于非 UObject 类型，你仍然要保持清醒的头脑，使用 RAII 原则，学会使用智能指针，并避免原始指针带来的危险。

这就是 C++ 带来的底层控制力，以及随之而来的内存管理责任。这正是我们 C# 开发者需要迈出的第一步，也是最重要的一步。

下一篇文章，我们将深入探讨 C++ 的指针、异常处理和模板，并对比它们与 C# 对应特性的异同。如果你有任何疑问，或者想提前知道某个主题，随时告诉我。