Unreal Engine의 C++ Cast<T> 함수는 어떻게 동작하는가?

먼저 API를 고르는 기준#

raw pointer가 gameplay 관점에서도 살아 있어야 한다면 먼저 IsValid(Object)를 확인한다. Cast가 non-null을 반환했다는 사실만으로 destroy 예정 object까지 사용할 수 있다는 뜻은 아니다.

UE5 Cast<T>의 큰 흐름#

Cast<T>는 source와 destination이 완전한 type인지 compile time에 확인한 뒤, null과 Unreal interface 여부, cast flag 사용 가능 여부를 차례로 나눈다.

EClassCastFlags는 모든 class의 고유 ID가 아니다#

UClass::ClassCastFlags는 common engine type cast를 빠르게 판별하기 위한 EClassCastFlags bit mask다. AActor, USceneComponent, UBlueprint 같은 제한된 engine category에 flag가 정의되어 있고 superclass의 flag가 subclass로 상속된다.

중요한 한계가 있다.

• 64-bit mask의 모든 bit를 임의의 game class마다 하나씩 배정하지 않는다.
• TCastFlags_V<T>의 기본은 CASTCLASS_None이다.
• custom game type 대부분은 target-specific bit가 없어 IsA path를 사용한다.
• flag가 있다고 정확한 class equality를 뜻하지 않는다. 해당 category 또는 descendant 관계를 나타낸다.

application code가 이 내부 flag를 직접 선택하거나 확장하기보다 Cast, IsA, ExactCast의 공개 의미에 의존해야 한다.

IsA는 raw UObject와 FObjectPtr를 구분해서 읽어야 한다#

raw UObject 계열의 canonical path는 UObjectBaseUtility::IsA다. 개념적으로 다음 관계를 확인한다.

1
Object->GetClass()->IsChildOf(TargetClass)

target UClass*가 null이면 의미 있는 class 관계를 검사할 수 없다. Object가 null인 상태에서 member function을 호출하는 것도 C++ undefined behavior이므로 다음처럼 guard한다.

1
bool IsMyActor(const UObject* Object)
2
{
3
    return Object && Object->IsA<AMyActor>();
4
}

ObjectPtr.cpp의 FObjectPtr::IsA는 raw UObject의 member 구현과 구분해야 한다. FObjectPtr path는 handle resolve와 access tracking을 포함할 수 있는 별도 overload다. 결과의 class 관계는 같아도 raw pointer 비용을 분석할 때 해당 구현을 그대로 대입하면 안 된다.

IsChildOf의 두 구현#

UStruct::IsChildOf는 자신이 target UStruct와 같거나 descendant인지 판단한다. engine의 compile-time 설정에 따라 두 구현 중 하나를 사용할 수 있다.

여기서 h는 inheritance depth다. 어떤 build가 어느 구현과 cast flag 경로를 선택하는지는 해당 engine branch의 macro 설정을 확인한다. editor 여부만으로 모든 branch의 값을 단정하지 않는다.

경로별 복잡도#

Cast 전체를 무조건 O(1) 또는 무조건 비싸다고 설명할 수 없다.

interface search나 object handle resolve까지 포함해 “모든 Unreal cast는 bit test 하나”라고 일반화하면 안 된다. 반대로 game hierarchy 깊이는 보통 제한적이므로 cast 몇 번만 보고 architecture를 바꿀 이유도 없다. hot path는 Unreal Insights나 platform profiler로 실제 빈도와 target을 측정한다.

Cast, CastChecked, ExactCast, IsA#

1
void TryActivate(UObject* Candidate)
2
{
3
    if (!IsValid(Candidate))
4
    {
5
        return;
6
    }
7

8
    if (AMyActor* Actor = Cast<AMyActor>(Candidate))
9
    {
10
        Actor->ActivateFeature();
11
    }
12
}

1
AMyActor* Actor = CastChecked<AMyActor>(KnownActorObject);

1
if (UMyExactAsset* Asset = ExactCast<UMyExactAsset>(Object))
2
{
3
    // UMyExactAsset의 subclass는 여기 들어오지 않는다.
4
}

1
if (Object && Object->IsA<UMyAsset>())
2
{
3
    // type relation만 확인
4
}

Unreal interface의 Blueprint-only 함정#

Blueprint가 C++로 선언된 Unreal interface를 구현해도 native C++ IInterface subobject가 생기는 것은 아니다. Blueprint-only 구현에는 object pointer만 있고 native interface pointer는 없을 수 있다.

이 때문에 다음 코드는 Blueprint-only implementation에서 null일 수 있다.

1
if (IInteractable* NativeInterface = Cast<IInteractable>(Object))
2
{
3
    NativeInterface->InteractNativeOnly();
4
}

Blueprint 구현과 override까지 호출해야 한다면 reflection path를 사용한다.

1
void TryInteract(UObject* Object, AActor* Instigator)
2
{
3
    if (!IsValid(Object) ||
4
        !Object->GetClass()->ImplementsInterface(
5
            UInteractable::StaticClass()))
6
    {
7
        return;
8
    }
9

10
    IInteractable::Execute_Interact(Object, Instigator);
11
}

Interfaces in Unreal Engine는 Execute_ wrapper가 C++ 구현과 Blueprint override를 모두 호출하기 위한 path라고 설명한다. native interface pointer 자체가 필요한 API에서만 Cast<IInteractable>을 사용한다.

Blueprint Cast node는 C++ template 호출과 동일하지 않다#

Blueprint의 Cast To node도 Unreal reflection 관계를 검사하지만 C++ Cast<T> template을 그대로 instantiate하는 것은 아니다.

1. Kismet compiler가 class→class, interface→class, class→interface, interface→interface 조합에 맞는 cast statement를 만든다.
2. class cast bytecode에는 target UClass literal이 들어간다.
3. VM은 class target이면 IsA, interface target이면 ImplementsInterface와 script-interface path를 사용한다.

Blueprint node에는 VM dispatch 비용이 더해지고 target class reference가 asset dependency에 참여할 수 있다. 이는 class hierarchy query 자체의 비용과 별도 축이다. cast node 하나의 CPU 비용, 반복 횟수, target Blueprint의 load dependency를 섞어서 “Cast To는 항상 비싸다”라고 결론 내리지 않는다.

C++ RTTI와의 경계#

Unreal Cast는 UObjectBase 또는 Unreal interface 계열을 대상으로 한다. plain C++ class hierarchy에는 UClass가 없으므로 사용할 수 없다.

1
struct INativeService
2
{
3
    virtual ~INativeService() = default;
4
};
5

6
struct FConcreteService final : INativeService
7
{
8
};

이 hierarchy의 checked downcast는 표준 dynamic_cast와 native RTTI 영역이다. UE module에서 필요하면 Module Properties의 bUseRTTI와 platform ABI를 검토한다. RTTI를 끈 build가 dynamic_cast를 static_cast로 바꾸어 주지는 않는다. 표준 cast의 자세한 전제는 C++ 캐스팅 글에서 다룬다.

FField와 FProperty도 UObject hierarchy가 아니므로 CastField<T>를 사용한다.

1
if (FStructProperty* StructProperty =
2
        CastField<FStructProperty>(Property))
3
{
4
    const UScriptStruct* Struct = StructProperty->Struct;
5
}

결론#

Cast<T>는 C++ RTTI의 값싼 복제품이 아니다. Unreal reflection이 이미 유지하는 UClass hierarchy와 interface metadata를 이용하는 UObject 전용 cast다. source와 target의 종류에 따라 cast flag, interface address, IsA 중 맞는 경로를 선택한다.

성능은 선택된 경로와 IsChildOf 구현 방식에 따라 다르다. outer walk는 inheritance depth에 비례하고, struct-array query와 cast flag, exact class 비교는 O(1)이다. interface와 object pointer는 추가 비용이 있을 수 있다. 그래서 API는 micro-optimization보다 의미로 고른다.

• mismatch가 정상: Cast와 null 검사
• mismatch가 invariant 위반: CastChecked
• exact runtime class만: ExactCast
• bool만: guarded IsA
• Blueprint-capable interface: ImplementsInterface + Execute_
• non-UObject: 표준 C++ type system과 RTTI 정책

Cast 성공은 object lifetime, ownership, network authority, gameplay readiness를 보장하지 않는다. type check와 object validity를 분리해서 검증해야 한다.

참고 자료#

• Epic Games: Cast
• Epic Games: CastChecked
• Epic Games: ExactCast
• Epic Games: UObjectBaseUtility::IsA
• Epic Games: UStruct::IsChildOf
• Epic Games: EClassCastFlags
• Epic Games: Interfaces in Unreal Engine
• Epic Games: FScriptInterface
• Epic Games: CastField
• Epic Games: Module Properties