[📚정보] 언리얼 오브젝트와 포인터

[오더리움(othereum)]

언리얼 오브젝트 포인터는 C++의 스마트 포인터와 전혀 다름

UPROPERTY 마킹된 raw pointer는 C++ 문법상 unmanaged처럼 보이지만 언리얼 GC가 추적하기 때문에 strong reference임

UPROPERTY 마킹되지 않은 raw pointer는 언리얼 프로퍼티 시스템(리플렉션)에 보이지 않기 때문에 GC가 추적할 수 없음

보통 GC는 모든 오브젝트에 대해 참조관계를 그래프로 그려서 reachability(도달성)를 추적함

그러다가 어떤 오브젝트가 더 이상 참조되지 않아 unreachable(orphaned)이라고 판단되면 삭제하는 식으로 동작함

쉽게 말해서 아무도 참조하지 않으면 삭제하는거임. 뭐 이건 이미 알고 있겠지만..

그러나 언리얼의 가비지 콜렉터에는 MarkPendingKill 이라는 기능이 있는데, reachable object라도 강제로 삭제할 수 있는 기능임

그럼 해당 object에 대한 strong references는 어떻게 되는거냐?

GC가 해당 reference(pointer)를 자동으로 null로 바꿔줌

덕분에 강제 삭제되더라도 dangling pointer가 되는 일이 없어 안전함

가장 흔한 예시가 위 문서에도 써있듯이 AActor::Destroy() 같은 기능임

액터는 게임 중간에 언제든 삭제될 수 있어야 하기 때문에 이런 기능이 있는 것임

UObejct에 대한 레퍼런스를 UObject가 아닌 Native C++에서 가지고 있다면...

이 경우 리플렉션 시스템이 못보기 때문에 strong ref가 될 수 없다 (참조중인 UObject에 대해 reachable한 것으로 인정받지 못함)

따라서 해당 UObject가 unreachable이 되어 GC에 의해 삭제되는 것을 막을 수도 없고, GC가 해당 reference를 자동으로 null로 만들어주지도 않기 때문에 삭제되었다는 사실조차도 알 수가 없어 위험하다

이런 경우를 위해서 TWeakObjectPtr이 있음. 삭제되었는지 여부라도 알 수 있게 해주는 친구임

스마트 포인터의 TWeakPtr과는 비슷한것 같으면서도 전혀 다른 녀석이니 헷갈리지 않도록 주의하셈

참고로 델리게이트도 내부적으로 UObject를 TWeakObjectPtr로 참조하도록 구현되어있음

그래서 BindUObject 함수가 따로 있는거임

삭제된 UObject에 대고 델리게이트 실행시켰다간 큰일나니까 적어도 등록 대상이 살아있는지는 알수있어야지

코드로 정리하면

UCLASS(...)

class UMyObject : public UObject

{

GENERATED_BODY()

UPROPERTY()

UAnotherMyObject* StrongRef; // GC가 추적해서 관리해줌. 참조 대상에 대해 소유권 있음

TWeakObjectPtr<UAnotherMyObject> WeakRef; // GC가 추적하지는 않음. 소유권은 없지만 살아있는지 조회해볼수는 있음

UAnotherMyObject* UnmanagedRef; // 위험함. 소유권도 없고 살아있는지도 알수없음

TWeakPtr<FMyData> WeakPtr; // 전혀 다른 놈. UObject랑 관련 없음 (native c++)

...

};

이상이 언리얼의 오브젝트 처리와 가비지 콜렉터에 관한 내용이고

스마트 포인터와 흔히 혼동하는 부분을 정리해주자면

C++에서 stack 객체의 storage class는 automatic storage duration임

생명주기가 언어적 개념인 '스코프 { } 내부' 라고 명확하게 정의됨

생명주기가 명확하기 때문에 심지어 예외가 발생하더라도 소멸자는 반드시 호출된다는 것이 보장됨

그래서 소멸자를 이용하면 동적(heap) 객체의 생명주기도 안전하게 관리할 수 있지 않겠냐는 아이디어에서 나온게 스마트 포인터임

생성자/소멸자를 이용해서 포인터 '스스로' 참조 횟수를 세도록 하는거임. 그래서 스마트 라고 부르는 것

포인터 스스로 참조 횟수를 센다는 부분이 중요함

스마트 포인터 스스로 직접 판단하기 때문에, 참조관계가 변경되는 '즉시' 레퍼런스 카운트를 갱신할 수 있음

그래서 스마트 포인터로 관리되는 오브젝트는 orphaned(고아)가 없음. 고아가 되는 즉시 바로 삭제하니까.

반면 GC 방식은 GC라는 외부 시스템이 참조관계를 '느긋하게' 추적함

도달성 계산이 정해진 주기에 따라 수행됨

void foo()

{

UMyObject* Obj = NewObject<UMyObject>();

...

}

이렇게 NewObject로 생성한 객체를 raw pointer에 담아도 바로 삭제되지 않는건 이런 이유 때문임

하지만 저렇게 생성한 객체를 strong ref로 담아두지 않으면 조만간 삭제되고 말겠지

마지막으로, 질문자가 올린 코드 스니펫에 오류가 있길래 설명짤로 마무리함

[코테(chakichan)]

최소 펄업,스마게,넥슨 셋중 한 곳에 나오신분 아닐까 싶을 정도로 지식의 깊이 남다르네요 오늘도 많은걸 배우고 갑니다, 정리 잘 해주셔서 감사합니다 오더리움님. 따로 글 올릴텐데 마지막으로 한 번만 봐주시면 감사하겠습니다.

[오더리움(othereum)]

그랬으면 좋겠지만 중소기업에서 유니티 만지고있다

[익명(14.52)]

굳

[무료디시콘(avdost)]

유니티 언리얼 둘 다 다룸?

[오더리움(othereum)]

ㅇㅇ - dc App

[익명(118.176)]

글 둘러보다가 사족남김 에디터랑 실 프로그램이랑 gc 돌리는 주기가 다른경우 많음 gc 쓸려나가는거 주의하면서 코딩해야함