Why are virtual methods considered early bound?
<p>One definition of binding is that it is the act of replacing function names with memory addresses.</p>

<p>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?  </p>

<p>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?! </p>

<p>thanx</p>

<p><br></p>

<p>EDIT:</p>

<p>1)  </p>

<pre><code>A a=new A();
a.M();
</code></pre>

<p>As far as I know, it is not known at compile time where on the heap (thus at which memory address ) will instance <code>a</code> 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 <code>a</code> be created during runtime ( here I’m assuming the address of method <code>a.M</code> will also be at same memory location as <code>a</code> )? </p>

<p>2)</p>

<blockquote>
  <p>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.</p>
</blockquote>

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