koobas.hobune.stream
How come start and update methods aren't virtual?
Hello everyone,
I was just wondering why (and how) Unity allows me to do the following in C#:
public void Start()
{
// Do something here
}
public void Update()
{
// Do something here
}
Do the Start and Update methods inherit from MonoBehaviour? Why is it that I don't have to override a virtual method to use Start and Update? Are they virtual methods?
Anyone that can shed some light on this will be praised and loved :)
Thanks
Rember to mark an answer as correct, so other people with the same question find it better:)
MonoBehaviour doesn't define the methods at all - they're not part of its interface. Unity uses a programming mechanism called reflection to check for the appearance of these special functions like Start, Update, Awake and so on. Simply put the Unity engine has predefined function naming conventions that it's trying to find in classes that subclass MonoBehaviour.
So you are not overriding anything from MonoBehaviour, but actually providing the functions for it.
I need more details about this. So did the parent class $$anonymous$$onoBehaviour call "start()", "Update", "Awake"? I mean: so when these functions are called/used?
And the most important one: what's the advantage of "reflection"? Why not just use overriding?
Unity uses reflection into your class to identify any special methods (Start, Update, OnApplicationQuit, etc) that you've defined. It will only invoke those methods. Given the number of special methods that MonoBehaviours support, it would be very inefficient to invoke every single one on every single script if they were all defined as virtual methods, especially since most of them wouldn't be overridden and would just be empty methods providing nothing but unnecessary overhead.
Tabbed away from the window for a couple $$anonymous$$utes and got beat to the punch. :-) Anton's answer is good.
Actually, reflection can detect if a method was overridden or not. So, it would be quite nice if all those methods were actually virtual (so writing override will give us the list of all available methods), and we wouldn't lose anything for not overriding them.
You could take that to feedback.unity3d.com. They just didn't implement it that way. Personally I don't think it's that big a deal.
While it's true that you could detect if a method is overridden or not, virtual methods are generally slower than non-virtual method regardless of if they are overridden or not. That's because virtual methods are executed through the virtual methods table ( vTable ). So it's generally an indirect method call.
Virtual methods are slower than non-virtual methods when the virtual dispatch is used (this can be avoided when you seal a class and in many other situations).
Yet, I am sure there's a virtual dispatch already happening (I don't know if they compile a delegate to call the Update method, or how exactly they do the call, but I am sure it is not a static dispatch). So, the only thing that would really change if those methods were virtual in the base class would be that they would be available to any IDE when we wrote "override". They would still get invoked the exact same way they are now, without adding any additional virtual dispatch.
