【UE 反射】反射的原理是什么？如何使用机制？

2024-08-29 10:39:32

关注

VIP【UE 反射】反射的原理是什么？如何使用机制？

静态类型检查确保了类型的早期一致性和高效的代码执行，但减少了灵活性。动态类型检查提供了更大的灵活性，但增加了运行时的开销和潜在的错误。反射作为一种动态特性，无论是在静态类型语言还是动态类型语言中，都提供了强大的运行时类型操作能力，但也伴随着性能和安全性方面的权衡。通过理解这些联系，开发者可以在不同的编程语言和应用场景中选择适合的类型检查方式和反射机制，以实现所需的动态行为和灵活性，同时保证性能和安全性。

开通可读全文 ·6k 人阅读

最低0.47元/天解锁文章

🙋‍♂️ 作者：海码007

📜 专栏：UE虚幻引擎专栏

💥 标题：【UE 反射】反射的原理是什么？如何使用机制？

❣️ 寄语：书到用时方恨少，事非经过不知难！

🎈 最后：文章作者技术和水平有限，如果文中出现错误，希望大家能指正，同时有问题的话，欢迎大家留言讨论。

0 拓展

在开始介绍反射之前，我想先了解下不同的语言，不同的类型检查机制和反射的联系。以及偏移量在反射中的作用是什么。（这部分知识有利于反射机制的深入理解）

官方参考文章

0.1 静态类型检查

静态类型检查 是在 编译时 对程序中的所有变量和表达式进行类型检查，以确保每个操作数、变量、函数调用等的类型都是一致和兼容的。其中C、C++、Java、C#都是静态类型检查的语言。其主要原理可以通过以下几个方面来解释：

0.1.1 静态类型检查的主要原理

类型声明和定义
在静态类型语言中，每个变量、函数参数和返回值等的类型在代码编写时就已经明确指定。这些类型信息是编译器进行类型检查的基础。
```
int a = 10;         // 变量a的类型是int
double b = 20.5;    // 变量b的类型是double
```
符号表（Symbol Table）
编译器在编译过程中维护一个符号表，用于存储所有变量、函数及其类型信息。符号表在语法分析阶段创建，并在语义分析阶段进行扩展和检查。
类型推导
有些静态类型语言支持类型推导，编译器可以根据上下文自动推导出变量的类型（如C++中的auto关键字）。
```
auto x = 10;       // 编译器推导x的类型为int
auto y = 20.5;     // 编译器推导y的类型为double
```
类型检查
编译器在编译过程中对所有表达式和语句进行类型检查，以确保类型一致性。例如，变量赋值时检查类型兼容性，函数调用时检查参数类型匹配，运算符操作时检查操作数类型。
```
int a = 10;
double b = 20.5;
a = b;    // 编译器会警告或错误，类型不兼容

void foo(int x) {
     
      }
foo(b);   // 编译器会警告或错误，类型不兼容
```

类型转换
静态类型语言通常支持显式类型转换和隐式类型转换。编译器在类型转换时进行检查，确保转换是合法的。

int a = 10;
double b = static_cast<double>(a);  // 显式类型转换
double c = a;                       // 隐式类型转换

0.1.2 编译器的工作流程

编译器的工作流程通常分为以下几个阶段，每个阶段都会涉及类型检查：

词法分析（Lexical Analysis）
将源代码转换为一系列标记（tokens），这些标记代表代码中的基本元素，如关键字、标识符、操作符等。
语法分析（Syntax Analysis）
根据语法规则将标记组织成语法树（parse tree 或 AST, Abstract Syntax Tree），表示程序的结构。
语义分析（Semantic Analysis）
进行类型检查，确保每个操作符和操作数的类型一致。建立和维护符号表，跟踪变量和函数的类型信息。
中间代码生成（Intermediate Code Generation）
将语法树转换为中间表示（IR, Intermediate Representation），这种表示比源代码更接近机器代码，但仍然与具体机器无关。
优化（Optimization）
对中间代码进行各种优化，提高程序执行效率。
目标代码生成（Code Generation）
将优化后的中间代码转换为目标机器代码。

0.1.3 静态类型检查的优点和缺点

优点

提高性能: 静态类型检查消除了运行时类型检查的开销，生成的代码更高效。
早期错误检测: 类型错误在编译时被捕捉，减少了运行时错误的发生。
代码可维护性: 明确的类型定义提高了代码的可读性和可维护性。

缺点

灵活性较低: 类型必须在编译时确定，减少了代码的灵活性和动态性。
开发速度较慢: 需要显式地声明类型，增加了编码工作量。

0.1.4 示例

以下是一个C++代码示例，演示了静态类型检查的基本原理：

#include <iostream>

int add(int a, int b) {
   
   
    return a + b;
}

int main() {
   
   
    int result = add(5, 3); // 编译时确定类型
    std::cout << "Result: " << result << std::endl;
    return 0;
}

在这个例子中，变量result的类型在编译时确定为int，函数add的参数类型也在编译时确定为int，编译器会在编译时检查这些类型信息，确保类型一致性和正确性。

通过静态类型检查，编译器可以在编译阶段发现并修正许多潜在的错误，提高程序的可靠性和性能。这种设计使得静态类型语言在大型、复杂的系统中具有显著的优势。

0.1.5 C++也可以在运行时类型检查

虽然C++主要依赖静态类型检查来确保类型安全性和性能，但它也提供了多种机制支持运行时类型检查，如RTTI、自定义类型检查机制和第三方库。通过这些机制，开发者可以在运行时识别和处理类型信息，实现更灵活和动态的程序行为。这种组合使得C++在需要高性能和类型安全性的同时，也能在某些场景下提供必要的动态类型处理能力。

接下来就详细介绍一下RTTI

RTTI（Runtime Type Information，运行时类型信息）是C++的一种机制，它允许程序在运行时获得类型相关的信息。RTTI的主要原理基于虚函数表（vtable）和类的继承关系。下面是RTTI的基本原理和实现机制：

RTTI基本原理

虚函数表（vtable）
当一个类包含虚函数时，编译器会为这个类生成一个虚函数表（vtable），其中包含了所有虚函数的指针。每个包含虚函数的类实例都有一个指向这个虚函数表的指针（称为vptr）。
RTTI数据
RTTI信息也会存储在虚函数表中。具体来说，编译器会在虚函数表中加入指向类型信息（如std::type_info对象）的指针。这个指针通常在虚函数表的某个固定位置。

RTTI的实现

RTTI的实现依赖于两个关键操作符：typeid和dynamic_cast。

typeid操作符用于获取对象的类型信息。它返回一个std::type_info对象，该对象包含类型的信息。type_info对象的实际内容由编译器生成和维护。

#include <iostream>
#include <typeinfo>

class Base {
   
   
public:
    virtual ~Base() = default;
};

class Derived : public Base {
   
   };

int main() {
   
   
    Base* base = new Derived();
    std::cout << "Type of base: " << typeid(*base).name() << std::endl;
    delete base;
    return 0;
}

在这个例子中，typeid(*base)会返回一个std::type_info对象，表示base指向的实际对象的类型。

dynamic_cast操作符用于进行安全的多态类型转换。它可以将基类指针或引用转换为派生类指针或引用。如果转换成功，返回目标类型的指针，否则返回nullptr（对于指针类型）或抛出std::bad_cast异常（对于引用类型）。

#include <iostream>

class Base {
   
   
public:
    virtual ~Base() = default;
};

class Derived : public Base {
   
   
public:
    void show() {
   
   
        std::cout << "Derived class method called" << std::endl;
    }
};

int main() {
   
   
    Base* base = new Derived();
    Derived* derived = dynamic_cast<Derived*>(base);
    if (derived) {
   
   
        derived->show();
    } else {
   
   
        std::cout << "dynamic_cast failed" << std::endl;
    }
    delete base;
    return 0;
}

在这个例子中，dynamic_cast<Derived*>(base)会检查base是否指向一个Derived对象，如果是，则返回Derived类型的指针，否则返回nullptr。

RTTI的工作流程

编译时:
- 编译器为每个包含虚函数的类生成虚函数表，并在虚函数表中添加指向类型信息的指针。
- 编译器生成type_info对象，用于表示每个类型的信息。
运行时:
- typeid操作符通过访问虚函数表中的类型信息指针，获取对象的类型信息。
- dynamic_cast操作符通过检查虚函数表中的类型信息，确定是否可以进行安全的类型转换。

RTTI的限制

性能开销:
- RTTI会增加一些运行时开销，因为它需要在虚函数表中存储类型信息，并在运行时进行检查。
仅适用于多态类:
- RTTI依赖于虚函数表，因此只适用于包含虚函数的类（多态类）。对于非多态类，RTTI无法使用。
可移植性:
- 不同编译器和平台对RTTI的实现可能有所不同，因此在某些情况下，RTTI可能会有可移植性问题。

0.2 运行时动态类型检查

运行时动态类型检查是在程序运行时进行类型检查，以确保操作数和表达式的类型是有效和兼容的。与静态类型检查不同，动态类型检查是在程序执行过程中进行的，这意味着类型信息在运行时确定。动态类型检查通常用于动态类型语言，如Python、JavaScript和Ruby。以下是运行时动态类型检查的详细解释和其在几种常见语言中的实现方式。