UE反射实现分析：C++特性

在前一篇文章中，介绍了UE的反射的基础概念，这篇文章开始研究UE的反射机制的具体实现。

在介绍UE的代码之前，需要先要介绍一些C++特性，虽然UE的反射实现是大量依赖UHT的代码生成的，但是也需要C++的语法特性支持，只有把这些特性还有它们背后的含义了解清楚，才能够更好地理解UE的反射机制。

本篇文章中介绍的C++的特性和标准描述均基于ISO/IEC 14882:2014，也就是C++14标准。

要介绍的实现反射依赖的C++特性，就是把C++中类型的信息通过什么样的方式存储下来供运行时访问。

class/struct

对于C++ 的类而言，需要着重关注的是内存布局，因为类实例本质就是一块内存，而如何解释这块内存，需要通过类的类型信息来确定。
在C++中struct和class来定义类，只有默认的访问控制权限有差别，在UE中则不同，USTRUCT和UCLASS则进行了严格的区分，USTRUCT不能具有反射函数。

数据成员

因为兼容C的以及语言特性的实现，C++还有POD的概念。而介绍POD则又先要介绍C++标准中的standard-layout class（[ISO/IEC 14882:2014 9.1.7]）：
A standard-layout class is a class that:

has no non-static data members of type non-standard-layout class (or array of such types) or reference,
has no virtual functions (10.3) and no virtual base classes (10.1),
has the same access control (Clause 11) for all non-static data members,
has no non-standard-layout base classes,
either has no non-static data members in the most derived class and at most one base class with
non-static data members, or has no base classes with non-static data members, and
has no base classes of the same type as the ﬁrst non-static data member.

因为C++在实现特性的时候会往原始的内存布局中插入或调整成员顺序，所以C++标准中对standard-layout class做了上述限定。

可以把POD理解为只有数据的类，并且数据成员的排列顺序是固定的（不能包含多个不同的访问控制权限，因为编译器有可能会混排，标准中没有做保证），除了内存对齐外，不会被插入额外的内存。

在我之前的一篇文章：结构体成员内存对齐问题里介绍了内存对齐。因为内存对其的存在，类内数据成员并不是严格的一个挨着一个存放的，内存布局中会有一些空隙，这样会有两个问题：

数据成员在类内的偏移地址是依赖于内存对齐的
不同的声明顺序会导致类布局的变化（编译器也有可能对不同的访问控制权限进行重排）

为了获取数据成员在类内的偏移值，而不用考虑上面一堆的东西，C++引入了一个特性：Pointers to members，翻译过来就叫做指向成员的指针，这部分内容的详细描述在ISO/IEC 14882:2014 §8.3.3中。

在我之前的一篇文章中，也对指向成员的指针做过比较详细的介绍：C++ 中指向类成员的指针并非指针。

指向类成员的指针，重点就是来获取数据成员、函数相对于类型的描述信息，比如数据成员在类布局中的偏移，成员函数的this偏移值、成员函数的原始函数指针，得到了这些信息才能通过类实例访问到具体的成员。

如以下类：

class ClassExample
{
public:
  	bool bBoolean;
  	int ival;
  	double dval;
    void func(int){}
};

来获取它三个成员的内部偏移值：

1
2
3

bool ClassExample::*bBoolean = &ClassExample::bBoolean;
int ClassExample::*ival = &ClassExample::ival;
double ClassExample::*dval = &ClassExample::dval;

通过LLVM-IR翻译之后可以更直观地看到：

1
2
3

store i64 0, i64* %1, align 8
store i64 4, i64* %2, align 8
store i64 8, i64* %3, align 8

如果把类定义中的func改成virtual呢？

1
2
3

store i64 8, i64* %1, align 8
store i64 12, i64* %2, align 8
store i64 16, i64* %3, align 8

可以看到内存布局的变化，这是因为类中有了虚函数，往类布局中插入了虚表指针，占用了8个字节。

小结一下：通过成员函数指针等特性，可以在编译时就确定数据成员在类布局中的偏移，通过该偏移+数据成员的类型大小（sizeof），就可以正确地访问到指定的成员所在的内存了。

但是，C++中也有一个限制，就是不能对位域取地址：

The address-of operator & shall not be applied to a bit-ﬁeld, so there are no pointers to bit-ﬁelds.

位域在UE中被广泛地应用于bool值，C++中对该用法有保证：

A bool value can successfully be stored in a bit-ﬁeld of any nonzero size.

并且，位域的分配和对齐是实现定义的：

[ISO/IEC 14882:2014 9.6 Bit-ﬁelds]Allocation of bit-ﬁelds within a class object is implementation-deﬁned. Alignment of bit-ﬁelds is implementation-deﬁned.

因为不能对位域进行取地址，所以在反射实现中需要对uint8 bEnable:1;做一些特殊处理，要能得到位域中的位。

以FBoolProperty中获取bool值的实现为例：

FORCEINLINE bool GetPropertyValue(void const* A) const
{
	check(FieldSize != 0);
	uint8* ByteValue = (uint8*)A + ByteOffset;
	return !!(*ByteValue & FieldMask);
}

同时兼容了NativeBool和bit-field。

对于uint8 bit_field:1;和bool native_bool;两种反射信息的生成，以反射信息中的UE4CodeGen_Private::EPropertyGenFlags::NativeBool来区别，具有该flag的是bool native_bool;。

成员函数

UE的反射函数都是成员函数，并且需要继承自UObject。

UE中成员函数实现反射，并没有依赖C++的指向成员函数的指针，它完全依赖UHT生成了一个统一原型的Thunk函数，在Thunk函数中调用真正执行的函数（包括从栈上取数据等操作）。

并且会为反射的函数生成用于传递给ProcessEvent函数的参数结构，以及每个参数、返回值生成属性的反射信息（它们的内存偏移都是相对于UHT生成的参数结构的）。

如以下函数：

1 2	UFUNCTION() bool func(int32 InIval);

UHT生成的Thunk函数为：

DEFINE_FUNCTION(URefObject::execfunc)
{
    P_GET_PROPERTY(FIntProperty,Z_Param_InIval);
    P_FINISH;
    P_NATIVE_BEGIN;
    *(bool*)Z_Param__Result=P_THIS->func(Z_Param_InIval);
    P_NATIVE_END;
}

用这种方式，统一了所有的反射函数的调用原型为：

1	void execfunc( UObject* Context, FFrame& Stack, RESULT_DECL )

每个反射的函数都可以从这个原型中获取自己的参数，从而执行真正的函数调用行为（或者执行蓝图字节码）。

enum

枚举值不是整数，但是它可以被提升为整数类型。

[ISO/IEC 14882:2014]Therefore, enumerations (7.2) are not integral; however, enumerations can be promoted to integral types as speciﬁed in 4.5.

在UE的UEnum中枚举值使用int64来存储，所以，只要我们知道了枚举的名字，还有它名字所对应的整数值，就可以在名字和整数值以及枚举之间进行相互转换了。

UHT会给添加了UENUM的枚举生成这些信息，并在运行时构造出UEnum实例存储这些信息。

UE中的Enum写法：

UENUM()
enum class EClassEnum: uint8
{
	A =0,
	B,
	C = 11,
	D
};

UHT生成的部分反射代码：

static const UE4CodeGen_Private::FEnumeratorParam Enumerators[] = {
    { "EClassEnum::A", (int64)EClassEnum::A },
    { "EClassEnum::B", (int64)EClassEnum::B },
    { "EClassEnum::C", (int64)EClassEnum::C },
    { "EClassEnum::D", (int64)EClassEnum::D },
};

基于反射UEnum进行字符串、枚举值的转换：

template<typename ENUM_TYPE>
static bool GetEnumValueByName(const FString& InEnumValueName, ENUM_TYPE& OutEnumValue)
{
    bool bStatus = false;
    UEnum* FoundEnum = StaticEnum<ENUM_TYPE>();
    FString EnumTypeName = FoundEnum->CppType;
    if (FoundEnum)
    {
        FString EnumValueFullName = EnumTypeName + TEXT("::") + InEnumValueName;
        int32 EnumIndex = FoundEnum->GetIndexByName(FName(*EnumValueFullName));
        if (EnumIndex != INDEX_NONE)
        {
            int32 EnumValue = FoundEnum->GetValueByIndex(EnumIndex);
            ENUM_TYPE ResultEnumValue = (ENUM_TYPE)EnumValue;
            OutEnumValue = ResultEnumValue;
            bStatus = true;
        }
    }
    return bStatus;
}

而且也可以访问蓝图中的Enum：

FString UFlibAppHelper::GetEnumNameByValue(TSoftObjectPtr<UUserDefinedEnum> EnumPath, int32 value)
{
    FString result;
    UUserDefinedEnum* Enumer = LoadObject<UUserDefinedEnum>(nullptr, *EnumPath.ToString());
    if (Enumer)
    {
        result = Enumer->GetDisplayNameTextByValue(value).ToString();
    }
    return result;
}

scoped enum

随便写一点点番外，C++的scoped enum。

C++11 引入了 scoped enum：

enum class EClassEnum{
	A = 0,
	B,
	C
};

为什么要引入这么语法呢？因为 C++11 之前的 enum，其枚举值得定义是位于整个所属名字空间的。C++ 标准中的描述：

[ISO/IEC 14882:2014 §7.2]The enumeration type declared with an enum-key of only enum is an unscoped enumeration, and its enumerators are unscoped enumerators.

下面代码就会出现重定义错误：

enum ENormalEnum{
	A = 0
};
enum EOtherEnum{
	A = 0
};

所以在一般写代码时会加上 namespace 来人为地区分枚举的名字空间：

namespace ENamespaceEnum
{
  enum Type
  {
    A = 0,
    B,
    C
  };
};

因为上面 Type 的枚举值是位于当前 namespace 的，所以就可以以下面这种形式来使用：

1
2
3

ENamespaceEnum::A;
ENamespaceEnum::B;
ENamespaceEnum::C;

这其实是一种弱类型枚举，枚举本身并不是一个类型。所以 C++11 引入了 Scoped Enum，可以理解为强类型枚举：

enum class EScopedEnum{
	A = 0,
	B,
	C
};

使用它可以具有与上面 namespace 形式一样的效果。

Scoped Enumeration 的值也是可以显式转换为数值类型的：

[ISO/IEC 14882:2014 §5.2.9]A value of a scoped enumeration type (7.2) can be explicitly converted to an integral type.

而且，如果 scoped enum 的基础类型没有被显式指定的话，它的默认基础类型是 int:

[ISO/IEC 14882:2014 §7.2]Each enumeration also has an underlying type. The underlying type can be explicitly speciﬁed using enum-base; if not explicitly speciﬁed, the underlying type of a scoped enumeration type is int.

在 LLVM 中，对 Scoped enum 的处理是在编译器前端做的，下列代码生成的 IR 代码：

enum ENormalEnum{
	A = 0,
	B,
	C
};
enum class EScopedEnum{
	A = 0,
	B,
	C
};

int main()
{
	printf("A:%d,B:%d,C:%d\n",A,B,C);
	printf("A:%d,B:%d,C:%d\n",EScopedEnum::A,EScopedEnum::B,EScopedEnum::C);
}

main 函数的 LLVM-IR：

; Function Attrs: uwtable
define i32 @main() #3 {
entry:
  %call = call i32 (i8*, ...) @_Z6printfPKcz(i8* getelementptr inbounds ([16 x i8], [16 x i8]* @.str, i32 0, i32 0), i32 0, i32 1, i32 2)
  %call1 = call i32 (i8*, ...) @_Z6printfPKcz(i8* getelementptr inbounds ([16 x i8], [16 x i8]* @.str, i32 0, i32 0), i32 0, i32 1, i32 2)
  ret i32 0
}

在生成 IR 时就没有符号信息，只剩常量了。

static的构造时机

UE里的反射技术也依赖了C++的static构造时机，如gen.cpp中的：

1	static FCompiledInDefer Z_CompiledInDefer_UClass_URefObject(Z_Construct_UClass_URefObject, &URefObject::StaticClass, TEXT("/Script/RefExample"), TEXT("URefObject"), false, nullptr, nullptr, nullptr);

C++标准中对static的构造时机介绍：

It is implementation-defined whether the dynamic initialization of a non-local variable with static storage duration is done before the first statement of main.

虽然标准里写的implementation-defined行为，但是几乎用到的编译器都是这么干的。