Hi there!
Welcome to the Unreal Engine Community!
Your question is a bit hard to decipher without more context of your project and use case, so I will give a fairly generic answer that will hopefully also help others.
-
Think about your design structure, for what period of time does the rest of your game code NEED your object to keep existing, so that no crash occurs if attempting to access? Consider just nulling a hard reference ( UPROPERTY() ) yourself.
-
The more you control the flow yourself, rather than hoping a bunch of soft/hard references will work out correctly, the happier you will be.
Since you’re writing the code, even if it involves user input, surely you know when no one needs the reference any more, and you can just null a hard reference yourself.
This avoids all the confusions that can arise with a soft reference, in a case that is simpler than coding the Unreal Engine Editor itself.
Of course there is a time and a place for using a soft reference, but are you really there?
Don’t you know what your code is doing and when it needs the ptr and when it doesn’t?
Unless you can make the case for truly needing a soft reference , I would say you should be managing the pointer yourself, nulling it when you don’t need it any more.
That won’t work for actors though, actors have to be destroyed directly anyway.
Actor.h
/**
* Destroy this actor. Returns true the actor is destroyed or already marked for destruction, false if indestructible.
* Destruction is latent. It occurs at the end of the tick.
* @param bNetForce [opt] Ignored unless called during play. Default is false.
* @param bShouldModifyLevel [opt] If true, Modify() the level before removing the actor. Default is true.
* @returns true if destroyed or already marked for destruction, false if indestructible.
*/
bool Destroy(bool bNetForce = false, bool bShouldModifyLevel = true );
So if your class is a UObject that is not an Actor, then what I’ve written above is relevant
Avoiding Dangling/Stale Pointers
One of the most OMG moments in any UE C++ Developer’s life is when they forget to UPROPERTY() a pointer, which protects you from stale pointer crashes:
How to avoid Dangling Pointer Crashes (Pointer passes != nullptr but crashes on access)
And then their game crashes 
, and then they add UPROPERTY() 
,
and then they make lots of $ 
because their game release 
has become stable
while doing lots of fancy things.
~
Conclusion:
Your most direct question seems to be if references within a class will still count after the object is destroyed, and the answer is no, those reference go when the class instance goes.
The larger question is why you would ever not know when it is time to clear all references to a UObject that your code is responsible for creating, you really should, you shouldn’t need a soft reference unless you yourself don’t understand what your code is doing or your use case is very complex, with so many interacting parts, like the UE Editor itself.
I wrote my own in-game world editor and enable people to create worlds together in regular internet steam multiplayer games, multiplayer world editing, and I’ve never once used a soft reference and my code doesn’t crash, and it is a full-fledged world-editor with people running around while stuff gets created and destroyed via a regular editor UI.
So I am just not convinced you can’t control your hard reference pointers yourself, and null them yourself, when you are done using them.
The more Control you take of the whole Flow of your Code Base,
The Faster You Get to a Stable Release!
Rama