What is the difference between Early and Late Binding?

Question

What is the difference between early and late binding?

Daugherty

Late and early binding – Bluing

Would I be wrong to say early = direct function call while late = call to function through a function pointer? It never ceases to amaze me how programmers have a way of taking simple concepts and making them seem way more complex than they are (as a show of intelligence?). Programming is inherently a very easy field of study until you get down to things like how a float type is made or the development of compilers. – Chemarin

Possible duplicate of Early and late binding – Drunkometer

Answer 1

The short answer is that early (or static) binding refers to compile time binding and late (or dynamic) binding refers to runtime binding (for example when you use reflection).

Konstanze

But the wikipedia article on late binding (en.wikipedia.org/wiki/Late_binding) says that "Late binding is often confused with dynamic dispatch, but there are significant differences". So are they the same or not? If they are the same, then that wikipedia page needs to be changed. – Seclusive

Better stackoverflow answer here https://mcmap.net/q/24986/-early-and-late-binding – Popple

Answer 2

In compiled languages, the difference is stark.

Java:

//early binding:
public create_a_foo(*args) {
 return new Foo(args)
}
my_foo = create_a_foo();

//late binding:
public create_something(Class klass, *args) {
  klass.new_instance(args)
}
my_foo = create_something(Foo);

In the first example, the compiler can do all sorts of neat stuff at compile time. In the second, you just have to hope that whoever uses the method does so responsibly. (Of course, newer JVMs support the Class<? extends Foo> klass structure, which can greatly reduce this risk.)

Another benefit is that IDEs can hotlink to the class definition, since it's declared right there in the method. The call to create_something(Foo) might be very far from the method definition, and if you're looking at the method definition, it might be nice to see the implementation.

The major advantage of late binding is that it makes things like inversion-of-control easier, as well as certain other uses of polymorphism and duck-typing (if your language supports such things).

Daugherty

Answer 3

Similar but more detailed answer from Herbert Schildt C++ book:-

Early binding refers to events that occur at compile time. In essence, early binding occurs when all information needed to call a function is known at compile time. (Put differently, early binding means that an object and a function call are bound during compilation.) Examples of early binding include normal function calls (including standard library functions), overloaded function calls, and overloaded operators. The main advantage to early binding is efficiency. Because all information necessary to call a function is determined at compile time, these types of function calls are very fast.

The opposite of early binding is late binding. Late binding refers to function calls that are not resolved until run time. Virtual functions are used to achieve late binding. As you know, when access is via a base pointer or reference, the virtual function actually called is determined by the type of object pointed to by the pointer. Because in most cases this cannot be determined at compile time, the object and the function are not linked until run time. The main advantage to late binding is flexibility. Unlike early binding, late binding allows you to create programs that can respond to events occurring while the program executes without having to create a large amount of "contingency code." Keep in mind that because a function call is not resolved until run time, late binding can make for somewhat slower execution times. However today, fast computers have significantly reduced the execution times related to late binding.

Quitt

"the object and the function are not linked until run time" This statement seems to imply that an object exists prior to run time. Aren't objects purely run time entities? Its the class of the object that exists at compile time. This could be better stated as "the function call and its implementation are not linked until run time" – Lowestoft

one example of late binding is in polymorphism (in OOP) that we use interfaces or abstract classes and then we bind to that in runtime. – Madid

Answer 4

Taken directly from http://word.mvps.org/fAQs/InterDev/EarlyvsLateBinding.htm

There are two ways to use Automation (or OLE Automation) to programmatically control another application.

Late binding uses CreateObject to create and instance of the application object, which you can then control. For example, to create a new instance of Excel using late binding:

 Dim oXL As Object
 Set oXL = CreateObject("Excel.Application")

On the other hand, to manipulate an existing instance of Excel (if Excel is already open) you would use GetObject (regardless whether you're using early or late binding):

 Dim oXL As Object
 Set oXL = GetObject(, "Excel.Application")

To use early binding, you first need to set a reference in your project to the application you want to manipulate. In the VB Editor of any Office application, or in VB itself, you do this by selecting Tools + References, and selecting the application you want from the list (e.g. “Microsoft Excel 8.0 Object Library”).

To create a new instance of Excel using early binding:

 Dim oXL As Excel.Application
 Set oXL = New Excel.Application

In either case, incidentally, you can first try to get an existing instance of Excel, and if that returns an error, you can create a new instance in your error handler.

Sulemasulf

I know this reply is old, and it's sourced from somewhere else, but it's not accurate. Late binding implies use of CreateObject, but CreateObject does not necessarily imply late binding. Binding does not apply to the method of instantiating an object, only to how it is declared. If you declare your object "As Excel.Application" it doesn't matter how you instantiate it. I always use CreateObject to instantiate object references to external libraries, that way I can switch between early and late binding and only have to switch one line (not two) -- the line that declares the object. – Hoover

Answer 5

In interpreted languages, the difference is a little more subtle.

Ruby:

# early binding:
def create_a_foo(*args)
  Foo.new(*args)
end
my_foo = create_a_foo

# late binding:
def create_something(klass, *args)
  klass.new(*args)
end
my_foo = create_something(Foo)

Because Ruby is (generally) not compiled, there isn't a compiler to do the nifty up-front stuff. The growth of JRuby means that more Ruby is compiled these days, though, making it act more like Java, above.

The issue with IDEs still stands: a platform like Eclipse can look up class definitions if you hard-code them, but cannot if you leave them up to the caller.

Inversion-of-control is not terribly popular in Ruby, probably because of its extreme runtime flexibility, but Rails makes great use of late binding to reduce the amount of configuration necessary to get your application going.

Daugherty

This point applies also to compiled languages that may include components compiled JIT and included at runtime to implement plugins or dynamic frameworks. Some canonical examples of this exist in Java, and of course Ruby and Python as well. An extreme example is Erlang, where the runtime can load two versions of any module at once for live upgrades/downgrades. So though a lot of Erlang code (most?) is written as statically typed pure functions, the runtime requirements mandate late binding and dynamic types under the hood. – Juratory

Answer 6

The easiest example in java:

Early (static or overloading) binding:

public class Duck {
    public static void quack(){
        System.out.println("Quack");
    }
}

public class RubberDuck extends Duck {
    public static void quack(){
        System.out.println("Piiiiiiiiii");
    }
}

public class EarlyTest {
    public static void main(String[] args) {
        Duck duck = new Duck();
        Duck rubberduck = new RubberDuck();

        duck.quack();
        rubberduck.quack(); //early binding - compile time
    }
}

Result is:

Quack
Quack

while for Late (dynamic or overriding) binding:

public class Duck {
    public void quack(){
        System.out.println("Quack");
    }
}

public class RubberDuck extends Duck {
    public void quack(){
        System.out.println("Piiiiiiiiii");
    }
}

public class LateTest {
    public static void main(String[] args){
        Duck duck = new Duck();
        Duck rubberduck = new RubberDuck();

        duck.quack();
        rubberduck.quack(); //late binding - runtime
    }
}

result is:

Quack
Piiiiiiiiii

Early binding happens in compile time, while late binding during runtime.

Polynesian

Answer 7

The compile time polymorphism also called as the overloading or early binding or static binding when we have the same method name with different behaviors. By implementing the multiple prototype of the same method and different behavior occurs in it. Early binding refers first compilation of the program . But in late binding object is runtime occurs in program. Also called as Dynamic binding or overriding or Runtime polymorphism.

Rotator

Answer 8

public class child()
{    public void method1()
     {     System.out.println("child1");
     }
    public void method2()
     {     System.out.println("child2");
     }

}
public class teenager extends child()
{    public void method3()
     {      System.out.println("teenager3");
     }
}
public class adult extends teenager()
{     
    public void method1()
    {    System.out.println("adult1);
         super.method1();
     }
}


//In java
public static void main(String []args)
{    ((teenager)var).method1();
}

This will print out

adult1
child1

In early binding the compiler will have access to all of the methods in child and teenager but in late binding (at runtime), it will check for methods that are overridden at runtime.

Hence method1(from child -- early binding) will be overridden by the method1 from adult at runtime(late binding) Then it will implement method1 from child since there is no method1 in method1 in teenager.

Note that if child did not have a method1 then the code in the main would not compile.

Pindus