# C++ TObjectPtr\<\> as a return type, is it good practice?

**URL:** <https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576>\
**Category:** Programming & Scripting\
**Tags:** unreal-engine, CPP, question\
**Created:** [June 25, 2024, 3:45am UTC](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576 "2024-06-25T03:45:13Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![famaldonadoos](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@famaldonadoos](https://forums.unrealengine.com/u/famaldonadoos)\
**Post date:** [June 25, 2024, 3:45am UTC](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576/1 "2024-06-25T03:45:13Z")

</div>

I read over the documentation regarding migration to UE5 and recommended good practices when using pointers in UE5. It seems they really want us to use TObjectPtr, which is fine. The documentation recommends adding `UPROPERTY()` to each instance of a `TObjectPtr<>` to ensure it is seen by garbage collector. With this being said, is it safe/recommended to return a `TObjectPtr<>` in UE5 C++?

Migration guide - [Unreal Engine 5 Migration Guide | Unreal Engine 5.4 Documentation | Epic Developer Community](https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-5-migration-guide#c++objectpointerproperties)

Pointers reference - [Smart Pointers in Unreal Engine | Unreal Engine 5.2 Documentation | Epic Developer Community](https://dev.epicgames.com/documentation/en-us/unreal-engine/smart-pointers-in-unreal-engine?application_version=5.2)

Thanks!

---

<div class="post-metadata">

**Author:** ![KaidoomDev](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/kaidoomdev/32/977996_2.png) [@KaidoomDev](https://forums.unrealengine.com/u/KaidoomDev)\
**Post date:** [June 25, 2024, 4:35am UTC](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576/2 "2024-06-25T04:35:36Z")

</div>

It should be fine just make sure to check if the object is Valid before accessing any of its members/functions.

You can always look at some of the built in engine functions as a reference. Returning a pointer is a common thing, what you do with it is where safety can be an issue if you don’t check for valid etc.

For **TObjectPtr** it’s very similar to your typical raw pointer but there are other advantages to using it. This forum [post](https://forums.unrealengine.com/t/why-should-i-replace-raw-pointers-with-tobjectptr/232781/2) contains some good info on why you would wanna use it.

---

<div class="post-metadata">

**Author:** ![PerunFSumsala](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@PerunFSumsala](https://forums.unrealengine.com/u/PerunFSumsala)\
**Post date:** [June 25, 2024, 3:20pm UTC](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576/3 "2024-06-25T15:20:29Z")

</div>

Returning TObjectPtr\<\> should be safe but not something I would recommend doing. TObjectPtr\<\> represents a lifetime dependency similar to standard c++ smart pointers, where the object referenced in the property should either not exist without the object holding it or the object itself depends on the referenced object, hence it not being GCed for as long as the reference exists.

We typically only use TObjectPtr\<\> in properties and then pass the objects around using raw pointers/references. In most functions, you don’t care about lifetimes since you are not freeing anything explicitly, it makes the signatures shorter/easier to read and you can convert between TObjectPtr\<\> and raw pointers either implicitly or easily using Get().

---

<div class="post-metadata">

**Author:** ![KaidoomDev](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/kaidoomdev/32/977996_2.png) [@KaidoomDev](https://forums.unrealengine.com/u/KaidoomDev)\
**Post date:** [June 25, 2024, 5:17pm UTC](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576/4 "2024-06-25T17:17:20Z")

</div>

I wouldn’t look at it as a smart pointer though, it’s very similar to a raw pointer and it behaves the same way in terms of garbage collection as indicated in the description.

 ![image](https://d3kjluh73b9h9o.cloudfront.net/original/4X/6/0/e/60e9389fa03eba2af4f6d815ca865d6cbfc627fd.png)

---

<div class="post-metadata">

**Author:** ![famaldonadoos](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@famaldonadoos](https://forums.unrealengine.com/u/famaldonadoos)\
**Post date:** [June 25, 2024, 7:37pm UTC](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576/5 "2024-06-25T19:37:44Z")

</div>

This makes a lot of sense, thank you to all that replied. I had the same suspicion regarding using it as a return type but wanted to confirm. Seems like `TObjectPtr<>` should be reserved for class or object properties in which you need to ensure the pointer ref is registered with the GC and made `nullptr` when owner is destroyed (correct me if I’m wrong on this), as suggested by @KaidoomDev 's [reply to my question](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576/4).

For now, I’ll leave my functions set as:

`AActor* foo()`

rather than:

` TObjectPtr<AActor> foo()` (what I was confused if I should change or not)

Thanks!

[Marking this as solution as a summary, thanks all that replied]

---

<div class="post-metadata">

**Author:** ![system](https://d3kjluh73b9h9o.cloudfront.net/original/4X/7/1/3/713c9d3f58553f0de89543d76a8a3a2779dc9fa4.png) [@system](https://forums.unrealengine.com/u/system)\
**Post date:** [July 25, 2024, 7:38pm UTC](https://forums.unrealengine.com/t/c-tobjectptr-as-a-return-type-is-it-good-practice/1915576/6 "2024-07-25T19:38:45Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
