What is runtime binding?
Runtime binding is a concept that allows your application to change or extend its behavior at runtime in ways that the compiler cannot fully determine. This doesn’t mean that the compiler is no longer involved. Just that your code needs a little extra information to complete some action and that information will only be available after your application starts running.
This can give your application the ability to add new features or change existing features. Any application that allows plugins or mods will make use of runtime binding.
First of all, in order to call a method, the compiler needs to know the method signature. This lets it know what arguments need to be passed to the method and what return type to expect. All this does though is get everything setup and ready to call the method and then after the method returns, then this tells the compiler what the return type will be. Calling the method itself needs an address.
That’s it mostly. Methods are little more than a pointer to some memory that holds instructions to be run. Sure, there’s other details such as the order that the arguments should be passed to the method and if the calling code or the method should be responsible for cleaning up the stack.
But what this episode is about is that pointer. Does the compiler know where it points?
If you call a method, then as long as the compiler knows the signature, it can output the proper code needed to call the method. But there’s no guarantee that the method has its implementation in the same source file that makes the call. An application can be composed of many source files and they all get compiled individually. It’s the job of the linker to connect the dots between a method called from one compilation unit and the method body defined in another compilation unit. As long as this connection can be made by either the compiler or the linker, then the method is bound during compile time.
Listen to the full episode for more information about runtime binding. There’s another aspect of runtime binding that I’ll explain in a future episode. This is similar but has more to do with binding data than methods. You can also read the full transcript below.
Transcript
Runtime binding is a concept that allows your application to change or extend its behavior at runtime in ways that the compiler cannot fully determine. This doesn’t mean that the compiler is no longer involved. Just that your code needs a little extra information to complete some action and that information will only be available after your application starts running.
This can give your application the ability to add new features or change existing features. Any application that allows plugins or mods will make use of runtime binding.
How does this work? Let me start by explaining compile time binding.
First of all, in order to call a method, the compiler needs to know the method signature. This lets it know what arguments need to be passed to the method and what return type to expect. All this does though is get everything setup and ready to call the method and then after the method returns, then this tells the compiler what the return type will be. Calling the method itself needs an address.
That’s it mostly. Methods are little more than a pointer to some memory that holds instructions to be run. Sure, there’s other details such as the order that the arguments should be passed to the method and if the calling code or the method should be responsible for cleaning up the stack.
But what this episode is about is that pointer. Does the compiler know where it points?
If you call a method, then as long as the compiler knows the signature, it can output the proper code needed to call the method. But there’s no guarantee that the method has its implementation in the same source file that makes the call. An application can be composed of many source files and they all get compiled individually. It’s the job of the linker to connect the dots between a method called from one compilation unit and the method body defined in another compilation unit. As long as this connection can be made by either the compiler or the linker, then the method is bound during compile time.
I’ll explain runtime binding right after this message from our sponsor.
A runtime binding is something that the compiler has no idea where the method comes from. It still knows about the method signature and can compile code to call the method but you have to provide the method address. The compiler doesn’t know where the method lives.
How could the compiler not know where a method lives? Isn’t that one of its main responsibilities?
Have you ever played the game of shells? A person takes a bean or some other marker and places it under a shell or maybe just under a cup. Other shells have no bean. Then the person starts moving the shells rapidly and sometimes even lifting a shell to let the bean slide over to another shell. Your job is to watch the bean and point to the location after a while. It can sometimes be difficult to follow the bean.
If we think of this bean as if it was a method address, then the compiler is very good at keeping track of all of them. But sometimes, you might want to introduce your own method pointer and then you can assign that method pointer to point anywhere you want. But that’s the problem. Giving a value to your method pointer to point to some method happens at runtime. The compiler is long gone by that time.
All the compiler knows is what signature your method pointer represents. And it can help make sure that you don’t assign a method address to your pointer that would break that signature. The compiler can also call a method through your method pointer because it knows all about the parameters and return type. The only thing the compiler doesn’t know is what exact method it’s actually calling. That’s because you provide the binding yourself when you assign an address to your function pointer.
So where do you get these addresses? Well, they could come from your code. This is a lot of trouble to go through though just to call a method so you’ll want to have a good reason for all this. And setting up a plugin system is an excellent reason.
Now, not all the plugins need to come from other developers. It’s actually a good idea to treat some of your own code as a plugin too. So what you do is create a collection of method pointers and add the address of some of your own methods to this collection. Then you can add more that your application discovers once it starts running.
Maybe you can look in a configuration file to find the identity of these extra methods. Or maybe you can open a directory and try loading dynamic link libraries that you find and then asking each library for certain method pointers. If you find any that match your criteria, then you add them to your collection.
What you end up with is a collection of method pointers that the compiler has helped you build but did not know exactly what they would be when your application was built. You can now call these methods.
There’s another aspect of runtime binding that I didn’t explain but is similar. This has more to do with binding data than methods. I’ll explain that in a future episode.