For example if I make a new c++ class which inherits AActor and I want to set some default properties with PostInitProperties(), why do I have to call Super::PostInitProperties()?
Because the compiler wouldnt know what exactly you want to do. What if you dont want to call the parent implementation? If the call is implicit, you could never tell it to not call it.
- Maybe you want to completely change the behaviour of the function and have the super implementation never be called?
- Or you want to have it called and just add a few properties?
Anyway, this is how inheritance for methods/functions usually work in any modern (and not so modern) OO language, since it gives you most control of the flow.
Hope that clears it up a bit!
Cheers,
Technically, you don’t HAVE to call it. However, depending on the scenario; not doing so can equal very bad things.
When you’re making a child class to a UObject or UClass, you most certainly want to call the Super (Parent) for most of the functions you override, because things like construction and destruction have a lot of work that you don’t want to recreate. And Epic put in a lot of effort to do the ground work for you.
By calling the Parent’s Super in an overridden function, you are allowed to “Extend” the code of that function, rather than having to recreate all of it. Failing to call the Super of that function, will result in none of the existing code of the parent being used.
Now, let us take a different scenario. Say I’ve made myself a Weapon class which is a child UActor. I’ve done my basic setups and Parent calls. Now I’m on to doing the custom functions I want for my game.
In this example, say I have a function that applies to any and every conceivable child weapon I plan on ever making under this Class.
For that function, I can code it once in the “MyWeapon” class, and just have any child objects call the parent function, so I never have to repeat the code in the children. SideNote, if you’re not going to add to or change the effect of a Parent function, there would really never be any need to declare/override it in the children.
Now, perhaps I have a function that does some basic setup for my weapons, but depending on what kind of child weapon I make, some additional work may be needed. I can do the basic code in the parent, and have the children objects call the parent function to get the basics out of the way, and then add on any additional logic that that specific child class would need.
Finally, I decide to make a function that applies to most, but not all of the children weapons I intend on making.
Again, I can code once and call the parent for when/where it applies. But let us say that I make a child weapon who uses most of the features of MyWeapon class, but not all. Perhaps my Main Class (MyWeapon) is best suited for mostly guns, but I want to use a lot of the same logic for something a bit different. Maybe I make a child “StickyBomb” from the MyWeapon class. I’ll have some functions names that I would still want to use, but completely different logic inside of them because there would be no similarity with a gun.
In this instance, I’d still use the function name (and maybe parameters) but just ignore calling the Super. This way I can truly override the whole thing without code fighting each other.
You see, by doing things this way, allow a common approach that can handle various ways of using it (inheritance)