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.
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.