본문 바로가기
UnrealEngine5/C++

TObjectPtr<T> 재정리

by 개발의 묘미(GaeMyo) 2025. 8. 24.
SMALL

TObjectPtr<T>

UObject 포인터를 가리키는 얇은(wrapping) 타입.

엔진의 메타데이터(UHT / UHT reflection)와 향후 내부 포인터 표현(ex: 참조 추적이나 안전한 ReLoc 등)을 대비해

기존의 UObj* 원시(raw)포인터 대신 권장되게 된 형태.

 

런타임에서 스마트포인터(참조 카운팅 등)는 아니며,

소유권을 바꾸거나 GC를 대신하지 않음.

 

 

 

이런 게 왜 있는가?

 

 

UE5(5라는게 중요)의 코드 베이스를 점진적으로 ( UObj*의 표현을 변경 가능한 형태로 )옮기기 위해 도입됨.

TObjectPtr을 쓰면 UHT / 리플렉션이 해당 필드를 추적하기 쉬워지고,

엔진 내부에서 포인터의 표현을 바꿀 때(ex: 간접화, 인덱스 기반 참조 등) 소스 호환을 유지하기 쉬움.

즉 향후 엔진 내부가 포인터를 다른 방식으로 바꿔도 코드 변경을 최소화하려는 준비성의 일환임.

 

TObjectPtr<T>은 얇은 래퍼로써 런타임 비용이 거의 없음.

UObject포인터 취급을 위한 타입 표기.

null을 허용하며 참조 카운트 X.

UPROPERTY로 선언하면 기존 UObject*와 동일하게 직렬화/리플렉션/GC 마킹 대상이됨.

 

 

 

확실히 구분해야 할 특징들

  1. 런타임 스마트포인터가 아니다
    ( TSharedPtr과 같은 참조 카운트, 자동 해제같은 기능이 없음. 즉 소유권 관리를 하지 않는다. )

  2. GC/리플렉션과의 관계
    UPROPERTY()로 선언된 TObjectPtr<UWhatever>은 기존 UPROPERTY()로 선언한 UWhatever*와 마찬가지로 엔진이 Serialize / GC Marking / Replication 대상으로 다룸.
    단, TObjectPtr 타입 자체만으로 UPROPERTY 어노테이션 없이 자동으로 GC에 수집되진 않음.
    (UPROPERTY 또는 AddReferencedObjects 등으로 등록 필요)

  3. 런타임 안전성
    TObjectPtr 자체는 UObject가 파괴되었는지 알려주지 않음.(Weak는 자동 무효화)
    파괴된 UObject에 대한 댕글링 포인터 문제가 존재할 수 있기에 멤버로 쓸 땐 UPROPERTY와 GC 스코프로 안전보장 받는 경우가 많음.

  4. 성능
    얇은 wrapper여서 원래의 UObject*와 거의 동일한 성능.
    런타임 오버헤드 거의 없음.

  5. 목적은 호환성과 미래 대비
    현재는 많은 부분들이 UObject*와 동일하지만, 엔진이 내부적으로 포인터 표현을 바꿀 때 TObjectPtr 사용부만 변환하면 되므로 마이그레이션 / 유지보수 이득이 큼.

 

 

 

 

반응형
SMALL

'UnrealEngine5 > C++' 카테고리의 다른 글

UE5에서의 UInterface, IInterface 재정리  (0) 2025.08.25
TWeakPtr<T> 재정리  (0) 2025.08.24
TUniquePtr 재정리  (0) 2025.08.24
TWeakObjectPtr<T> 재정리  (0) 2025.08.24
double-free 취약점 재정리(미완, 검토 필요)  (0) 2025.08.24
TSharedRef<T> 재정리  (0) 2025.08.24
TSharedPtr<T> 재정리  (3) 2025.08.24
FName && FString && FText  (1) 2025.08.18