Early and late binding

Question

I'm trying to get my head around when early/late binding occurs in C#.

Non-virtual methods are always early bound. Virtual methods are always late bound: the compiler inserts extra code to resolve the actual method to bind to at execution time and checks for type safety. So subtype polymorphism uses late binding.

Calling methods using reflection is an example of late binding. We write the code to achieve this as opposed to the compiler. (E.g. calling COM components.)

VB.NET supports implicit late binding when Option Strict is off. An object is late bound when it is assigned to a variable declared to be of type Object. The VB compiler inserts code to bind to the right method at execution time and to catch invalid calls. C# does not support this feature.

Am I heading in the right direction?

What about calling delegates and calling a method through an interface reference? Is that early or late binding?

Hebetate

Answer 1

Everything is early bound in C# unless you go through the Reflection interface.

Early bound just means the target method is found at compile time, and code is created that will call this. Whether its virtual or not (meaning there's an extra step to find it at call time is irrelevant). If the method doesn't exist the compiler will fail to compile the code.

Late bound means the target method is looked up at run time. Often the textual name of the method is used to look it up. If the method isn't there, bang. The program will crash or go into some exception handling scheme at run time.

Most script languages use late binding, and compiled languages use early binding.

C# (prior to version 4) doesn't late bind; they can however use the reflection API to do it. That API compiles to code that looks up function names by digging through assemblies at run time. VB can late bind if Option Strict is turned off.

Binding usually has an effect on performance. Because late binding requires lookups at runtime, it is usually means method calls are slower than early bound method calls.

---

For a normal function, the compiler can work out the numeric location of it in memory. Then it when the function is called it can generate an instruction to call the function at this address.

For an object that has any virtual methods, the compiler will generate a v-table. This is essentially an array that contains the addresses of the virtual methods. Every object that has a virtual method will contain a hidden member generated by the compiler that is the address of the v-table. When a virtual function is called, the compiler will work out what the position is of the appropriate method in the v-table. It will then generate code to look in the objects v-table and call the virtual method at this position.

So, there is a lookup that occurs for the virtual function. This is heavily optimized so it will happen very quickly at run-time.

Early bound

• The compiler can work out where the called function will be at compile time.
• The compiler can guarantee early (before any of the programs code runs) that the function will exist and be callable at runtime.
• The compiler guarantees that the function takes the right number of arguments and that they are of the correct type. It also checks that the return value is of the correct type.

Late-binding

• The lookup will take longer because its not a simple offset calculation, there are usually text comparisons to be made.
• The target function may not exist.
• The target function may not accept the arguments passed to it, and may have a return value of the wrong type.
• With some implementations, the target method can actually change at run-time. So, the lookup may execute a different function. I think this happens in the Ruby language, you can define a new method on an object while the program is running. Late-binding allows function calls to start calling a new override for a method instead of calling the existing base method.

Neustria

I think you meant to say "The VB language itself doesn't late bind..." – Widener

Actually, I don't use VB... so I don't know a lot about that. I did mean C#, but it looks like I was just repeating myself. I would imagine though that you're correct, so I'll fix it up! – Neustria

With the dynamic keyword, late binding will be available in C# 4. – Regulation

Dynamic typing is not the same as late binding. The difference is subtle, but it's important. Late binding still binds to a type, it just does it at runtime. Dynamic typing does not bind; instead, it resolves member information at runtime irrespective of type. – Widener

Thanks for the above comment, didn't know that – Chally

Late binding doesn't bind to a type. The variable is declared without a type and the method is resolved by name at runtime irrespective of type. – Philippi

"For an object that has any virtual methods, the compiler will generate a v-table.". This is a bit incorrect - "class", not "object". – Women

What about delegates aren't they a late binding mechanism ? – Hazem

@IvanRuski I don't think so. At compile time, all of the arguments types that a delegate accepts are known. So, at compile time (which is 'early') rather than runtime (which is 'late'), the compiler can guarantee that the call will work. – Neustria

@ScottLangham I would argue that looking up vmethod (runtime dispatching) is late binding. You write "Early bound just means the target method is found at compile time" but the target method is not found at compile time. the cil gets generated with callvirt on the base method. what you are referring to is dynamic vs strongly typed languages. Because c# is the later you are not able to get around the type safety. Except with a upcast (e.g. var mycar = (car) obj) which just instructs the c# compiler to treat the obj as the new type but methodcalls still get checked and dispatched at runtime, – Typescript

@ScottLanghamthis for example this will compile: var train = new train(); Object obj = train; Car car = (car) obj; car.carspecificmethod(); but at runtime it will fail because carspecificmethod is not present on the runtimetype which is train. and thus invalidating your statement "If the method doesn't exist the compiler will fail to compile the code.". – Typescript

@S.JohnFagone There are ways around things in the language. Just like you can mark a class member as private. It's reasonable to say in that case that it's marked as private so that it cannot be read by the implementation of other methods in other classes. But, then, you can use reflection to still access it with valid C#. – Neustria

@ScottLangham not the same. my point above was that the check and resolve happens no matter what the same time at run time (late binding). If you upcast something you just tell the "local" compiler to trust you but the check and reolve (dispatch) of the method happens anyway on runtime. – Typescript

Answer 2

C# 3 uses early binding.

C# 4 adds late binding with the dynamic keyword. See Chris Burrow's blog entry on the subject for details.

As for virtual versus non-virtual methods, this is a different issue. If I call string.ToString(), the C# code is bound to the virtual object.ToString() method. The code of the caller does not change based on the type of the object. Rather, virtual methods are called through a table of function pointers. An instance of object refers to object's table pointing at it's ToString() method. An instance of string has it's virtual method table pointing at it's ToString() method. Yes, this is polymorphism. but it is not late binding.

Scatterbrain

I don't agree completely with this explanation. In C# marking an instance method or field as virtual means derived type can override the base type implementation in the inheritance chain. With virtual methods, the CLR knows which method to call at run time based on the run time object instance. Probably, the only part I agree with you is, it is an implementation of polymorphism. Then you cause confusion by saying it is not late binding. It is late binding because CLR can only call the correct run time type implementation when it knows the run time type of the object instance. – Haroldson

Answer 3

In most cases early binding is what we do on a daily basis. For example, if we have have an Employee class available at compile time, we simply create the instance of that class and invoke any instance members. This is early binding.

//Early Binding
**Employee** employeeObject = new **Employee**();
employeeObject.CalculateSalary();

On the other hand, if you don't have the knowledge of the class at compile time, then the only way is to late bind using reflection. I have come across an excellent video explaining these concepts -- here's the link.

Inexpert

Answer 4

Its a very old post but wanted to add more info to it. Late binding is used when you dont want to instantiate object at compile time. In C# you use Activator to call bind object at runtime.

Geoff

Answer 5

Early Binding

The name itself describes that compiler knows about what kind of object it is, what are all the methods and properties it contains. As soon as you declared the object, .NET Intellisense will populate its methods and properties on click of the dot button.

Common Examples:

ComboBox cboItems;

ListBox lstItems; In the above examples, if we type the cboItem and place a dot followed by, it will automatically populate all the methods, events and properties of a combo box, because compiler already know it's an combobox.

Late Binding

The name itself describes that compiler does not know what kind of object it is, what are all the methods and properties it contains. You have to declare it as an object, later you need get the type of the object, methods that are stored in it. Everything will be known at the run time.

Common Examples:

Object objItems;

objItems = CreateObject("DLL or Assembly name"); Here during the compile time, type of objItems is not determined. We are creating an object of a dll and assigning it to the objItems, so everything is determined at the run time.

Early Binding vs. Late Binding

Now coming into the picture…

Application will run faster in Early binding, since no boxing or unboxing are done here.

Easier to write the code in Early binding, since the intellisense will be automatically populated

Minimal Errors in Early binding, since the syntax is checked during the compile time itself.

Late binding would support in all kind of versions, since everything is decided at the run time.

Minimal Impact of code in future enhancements, if Late Binding is used.

Performance will be code in early binding. Both have merits and demerits, it's the developer decision to choose the appropriate binding based on the scenario.

Sobel

Answer 6

In very simple terms, early binding happens at compile time and the compiler has the knowledge about the type and all it's members, and late binding happens at run time, the compiler doesn't know anything about the type and it's members. I have come across an excellent video on youtube which explains these concepts.

http://www.youtube.com/watch?v=s0eIgl5iqqQ&list=PLAC325451207E3105&index=55&feature=plpp_video

http://www.youtube.com/playlist?list=PLAC325451207E3105

Bluecollar

Answer 7

This article is a guide to building a .net component ,using it in a Vb6 project at runtime using late binding, attaching it's events and get a callback.

http://www.codeproject.com/KB/cs/csapivb6callback2.aspx

This article is a guide to building a .NET component and using it in a VB6 project. There are many samples about this issue, so why did I write a new one? In my humble opinion, in other articles, the missing part is to attach its event at runtime. So in this article, we will build a .NET component, mark it as a COM visible component, use it at runtime in VB6 and attach to its events.

https://www.codeproject.com/Articles/37127/Internet-Explorer-Late-Binding-Automation

Most developers often need Internet Explorer automation, which basically means opening a browser, filling some forms, and posting data programmatically.

The most common approach is to use shdocvw.dll (the Microsoft Web Browser control) and Mshtml.dll (the HTML Parsing and Rendering Component), or Microsoft.Mshtml.dll which is actually a .NET wrapper for Mshtml.dll. You can get more information about Internet Explorer - About the Browser here.

If you pick the above method and DLLs, let's see some of the problems you may have to deal with:

You have to distribute these DLLs because your project would be dependent to these DLLs, and this is a serious problem if you cannot deploy them correctly. Simply do some Googling about shdocvw and mshtml.dll distributing problems, and you'll see what I'm talking about. You have to deploy an 8 MB Microsoft.mshtml.dll because this DLL is not part of the .NET framework. In this case, what we need to do is use a late binding technique. Writing our own wrappers for the above mentioned DLLs. And of course, we'll do this as it is more useful than using these DLLs. For instance, we won't need to check if the document download operation is complete because IEHelper will do this for us.

Annettannetta