Why C++ casting is more efficient (for memory) and blueprint casting - NOT?

[Wisewalker]

@FrantisekSumsala

But in general you can have UBaseClass in C++ that has a TSubclassOf property and a DoSomething() BlueprintImplementableEvent function and you can create a child blueprint in which you assign the actual class reference and implement the event. Then you can access the referenced class and invoke the function through the base class instead of having to cast to the concrete blueprint type.

Sorry, if I am being dumb, just to be clear, in this case we still create cast, but to the C++ UBaseClass which result in hard-referencing the class from TSubclassOf property. However, in this case hard-referencing is reasonable (because object was spawned and its class was loaded to memory anyway)

@FrantisekSumsala

As @Auran131 rightly stated, this sort of does not matter once you deal with actual instantiated objects since those have to be loaded already. To really minimize the amount of hard references, you have to use soft references and lazy load things as they are needed. What we are discussing is sort of specific to cast nodes and how they are included in the reference chain.

I understand now that without assist from soft references and interfacecs managing memory effectively can be hard (because hard references to all used assets will be created anyway and to decrease the amount of unnecessary loads to memory we can use all the aforesaid methods + appropriate classes hierarchies and structure).

@FrantisekSumsala

The reason why casting to C++ classes is recommended is twofold:

1. C++ classes don’t contain asset references (they can but may the lord have mercy on your soul if you do). You can declare an asset reference in C++ but it will be empty for the class itself and you fill it in a child blueprint. So if you were to cast to the blueprint it would load it but casting to the parent C++ class doesn’t since it has nothing to load.
2. C++ classes can declare virtual functions that are implemented/overridden in the child blueprints. So you can execute any desired functionality of the child blueprint by calling functions on the parent C++ class without having to load anything as per point 1.

This ties to the overall recommended approach to structuring code in UE where you create a base C++ class, declare the API of the object in it along with any core system functionality and then create child blueprints off of it that reference assets and implement any specialized functionality that might need to be changed often.

The uppermentioned information means that following this strategy we do not exclude\reduce hard-references, but decrease the amount of unnecessary loads to memory because BPs inheriting from some C++ class can also have certain hard-refs to assets unlike C++ class (where it is not recomended, i.e. bad practice)

PS: really appreciate your help and spent time in case you won’t answer this