UPROPERTY(), to Use or Not to Use

Around the 12 minute mark, the UPROPERTY() specifier is removed from the UAnimInstance since we probably won’t be accessing it from a Blueprint.

Now this is all well and good and makes logical sense to do, but there is a reason beyond BP use to keep the UPROPRTY(). That reason is that anything marked as a UPROPERTY() will not be automatically collected and dumped by the Garbage Collector. Usually, it doesn’t matter if things like floats, ints, bools, etc get picked up in the GC, but with references to UObjects (like our UAnimInstance*, an AFirstPersonCharacter*, or an ABallProjectile*), it is best to keep the specifier on there to prevent accidental collection.

The general practice encouraged by Epic is to always have UPROPERTY() above any UObject reference, even if there are no parameters in the tag like so:

UPROPERTY()
UAnimInstance* AnimInstance;

This will prevent the UAnimInstance from being collected and makes it easy to just add in parameters quickly if we decide later that we should be able to access or view this from Blueprint.

Just going to tag @sampattuzzi so he’s aware of this.

That’s good to know, especially if one is expecting that all class elements will be there when you want them to be. I would not expect that private variables in the .h file would get grabbed by GC until the object itself is destroyed. (Obviously, expecting just the opposite with local variables declared within methods).

I just patched the video at 12:23. Could you make sure that okay now?

Looks good now @sampattuzzi!

1 Like

Privacy & Terms