[ACCEPTED]-Early and late binding-late-binding

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

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

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

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

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

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

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

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

So, there 3 is a lookup that occurs for the virtual 2 function. This is heavily optimized so it 1 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.

C# 3 uses early binding.

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

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

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

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

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

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

Early Binding

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

Common Examples:

ComboBox cboItems;

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

Late Binding

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

Common Examples:

Object 21 objItems;

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

Early Binding vs. Late 15 Binding

Now coming into the picture…

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

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

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

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

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

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

In very simple terms, early binding happens 6 at compile time and the compiler has the 5 knowledge about the type and all it's members, and 4 late binding happens at run time, the compiler 3 doesn't know anything about the type and 2 it's members. I have come across an excellent 1 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

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

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

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

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

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

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

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

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