Why are virtual methods considered early bound?

Posted by AspOnMyNet on Stack Overflow See other posts from Stack Overflow or by AspOnMyNet
Published on 2010-03-10T18:51:30Z Indexed on 2010/03/12 3:37 UTC
Read the original article Hit count: 319

Filed under:

One definition of binding is that it is the act of replacing function names with memory addresses.

a) Thus I assume early binding means function calls are replaced with memory addresses during compilation process, while with late binding this replacement happens during runtime?

b) Why are virtual methods also considered early bound (thus the target method is found at compile time, and code is created that will call this method)? As far as I know, with virtual methods the call to actual method is resolved only during runtime and not compile time?!

thanx


EDIT:

1)

A a=new A();
a.M();

As far as I know, it is not known at compile time where on the heap (thus at which memory address ) will instance a be created during runtime. Now, with early binding the function calls are replaced with memory addresses during compilation process. But how can compiler replace function call with memory address, if it doesn’t know where on the heap will object a be created during runtime ( here I’m assuming the address of method a.M will also be at same memory location as a )?

2)

v-table calls are neither early nor late bound. Instead there's an offset into a table of function pointers. The offset is fixed at compile time, but which table the function pointer is chosen from depends on the runtime type of the object (the object contains a hidden pointer to its v-table), so the final function address is found at runtime.

But assuming the object of type T is created via reflection ( thus app doesn’t even know of existence of type T ), then how can at compile time exist an entry point for that type of object?

© Stack Overflow or respective owner

Related posts about c#