Do I need to set UPROPERTY values to null when UObject destroyed?

Development Programming & Scripting
1

I recently studied.
That UPROPERTY variables use strong references.
So I have a question.
We know that complex strong reference relationships make GC difficult.
Does the act of setting the value to null when the object is destroyed help with GC performance?
Here’s my simple example.

header

#pragma once
    
    #include "CoreMinimal.h"
    #include "GameFramework/Actor.h"
    #include "TestActor.generated.h"
    
    UCLASS()
    class ATestActor : public AActor
    {
       GENERATED_BODY()
       
    public:   
       ATestActor();
    
    protected:
       virtual void BeginPlay() override;
       virtual void EndPlay(const EEndPlayReason::Type EndPlayResult) override;
    
    public:
    
        UPROPERTY()
        class ABaseCharacter* Character;
    };

source

 #include "TestActor.h"
    
    //..
    void ATestActor::EndPlay(const EEndPlayReason::Type EndPlayResult)
    {
        // do we need to do this?
        Character = nullptr;    
        Super::EndPlay(EndPlayResult);
    }

Is it recommended?
Or is the engine already doing it?

2

That is easy enough and you can memory it like this:

  1. when UObject is ok, and you nullify all Ptrs to this UObject, GC will destroy it, everything is ok (UObject is destroyed, Ptrs are NULL)

  2. when YOU destroy UObject, GC is out of business and YOU should nullify all Ptrs to this UObject right after destroying to be safe when using them (those Ptrs). Once again everything is ok (UObject is destroyed, Ptrs are NULL)

GC gives much help because of 1) - you can just nullify all Ptrs and simply forget about UObject

3

Oh, so it’s important to actively nullify it.

But in fact, in development, there are many cases where you don’t know who is referencing the destroyed object. In order to actively nullify it, you need a device that manages it?

4

In most cases, you actively nullify only those objects, that you actively created. So in that case you know precisely who is this object referenced by. If code is created in that style, then you rarely need to destroy an object that wasnt created by you.