Why should I replace raw pointers with TObjectPtr?

I am reading the UE5 migration guide (Migration Guide | Unreal Engine Documentation), and I see that TObjectPtr is now recommended over raw pointers. But the only thing the guide says about what this new type does is this:

This system adds dynamic resolution and access tracking in editor builds

What exactly does “dynamic resolution” and “access tracking” mean? How is this beneficial to me? The rest of the migration guide talks about how and where to use them, but doesn’t explain what functionality they provide. I went into the TObjectPtr header file (ObjectPtr.h) to look for more information, but unfortunately I didn’t see any useful comments on what they do.

Maybe I missed a page in the documentation that really went into the benefits of this change? I don’t feel convinced that I should make this change to my project. My project seems to work fine without them, and wrapping my pointers in TObjectPtr will not make my code more readable.

“Access tracking” means that you can actually detect when the object is being used. This can be used for example in deciding which objects to put where in an input stream, to put objects in the order they will be accessed. (Dunno if they do exactly that right now, but that kind of thing is often very helpful!)

Presumably they can also add checks in editor/debug modes where if you were to assign some invalid pointer to the value, you’d get an assert right where it happens, rather than a crash sometime much later when you try to use the bad pointer. (You’d get this from bad casts etc.)

Having worked on reflection systems of various kinds, I’m actually surprised they’ve managed to push raw pointers as far as they have. That would never have been possible without the UnrealHeaderTool, but even with that, it looks to me like an old habit that needs to go away.

1 Like

Well the most basic and fundamental incentive for doing so is because Epic has decided to adopt this standard for pointers. TObjectPtr is a template made by Epic which means it gives Unreal Engine easy access to all variables that use that template. This in turn means that whatever new feature/code/system they design will probably assume that you are using TObjectPtr’s and hence adopting this new standard is important for ensuring your code is compatible with future releases and everything is funcitoning as intended.


Well the most basic and fundamental incentive for doing so is because Epic has decided to adopt this standard for pointers

Sure, that’s very apparent. However, consider these three snippets from the migration guide:

TObjectPtr … an optional replacement for raw object pointers in editor builds

Although it is optional, we recommend using TObjectPtr<T> over T*

TObjectPtr … may improve your experience when developing in editor builds

So, the gist of what I’ve found out is its not mandatory (this is apparent since my build still runs without adding them), and it ‘may’ help interacting with the editor (I’m interested in this). I just would really like to know some more details to motivate me to make this change.

In the first paragraph in the the “Mandatory Updates” section:

Some of these changes are mandatory, while others are optional but recommended in UE5EA, and will become mandatory in future versions of UE5.


Good catch! If I must do it, then I must do it lol

1 Like

I wonder if this means that the editor will crash less when reloading C++ libraries, or force-deleting assets? That’d be nice.

TObjectPtr also ensures the pointer is initialized.

Found an issue caused by a non-null initial value in a marketplace plugin the other day, in fact.

(I realize this thread is old, but it’s one of the top google links for ‘TObjectPtr ue5’, so…)

1 Like

Honestly that is the main reason to use it. Creating new member pointer variables you can quickly forget initializing it with a nullptr.

Sadly Visual Studio based builds don’t really track this… I saw so many issues between debug and release builds during the past years.