Virtual methods and late binding

  • Thread starter Thread starter trubar a
  • Start date Start date
T

trubar a

hi

1) 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?!



2) Assume:

• B1 defines methods virtualM() and nonvirtualM(), where former method
is virtual while the latter is non-virtual
• B2 derives from B1
• B2 overrides virtualM()
• B2 is defined inside assembly A
• Application app doesn’t have a reference to assembly A

In the following code application app dynamically loads an assembly A,
creates an instance of a type B2 and calls methods virtualM() and
nonvirtualM():

Assembly a = Assembly.Load( “A” );
Type t= a.GetType ( “B2” );
B1 a = ( B1 ) Activator.CreateInstance ( “t” );

a.virtualM();
a.nonvirtualM();

a) Is call to a.virtualM() considered early binding or late binding?

b) I assume a call to a.nonvirtualM() is resolved during compilation
time?

3) Does the term late binding refer only to looking up the target
method at run time or does it also refer to creating an instance of
given type at runtime?

thanx
 
1) One definition of binding is that it is the act of replacing
function names with memory addresses.
Click to expand...

I would use another definition.

The time of binding is when it is found out whether the member
exists or not.
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?
Click to expand...

No. See above. Early binding means that the presence of the member
is checked at compile time. Late binding mean that its checked
at 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?!
Click to expand...

See above.
2) Assume:

• B1 defines methods virtualM() and nonvirtualM(), where former method
is virtual while the latter is non-virtual
• B2 derives from B1
• B2 overrides virtualM()
• B2 is defined inside assembly A
• Application app doesn’t have a reference to assembly A

In the following code application app dynamically loads an assembly A,
creates an instance of a type B2 and calls methods virtualM() and
nonvirtualM():

Assembly a = Assembly.Load( “A” );
Type t= a.GetType ( “B2” );
B1 a = ( B1 ) Activator.CreateInstance ( “t” );

a.virtualM();
a.nonvirtualM();

a) Is call to a.virtualM() considered early binding or late binding?
Click to expand...

Early. All C# except with the 4.0 dynamic keyword is early binding.
b) I assume a call to a.nonvirtualM() is resolved during compilation
time?
Click to expand...

Depends on what you mean by resolve.
3) Does the term late binding refer only to looking up the target
method at run time or does it also refer to creating an instance of
given type at runtime?
Click to expand...

The first.

Arne
 
Virtual methods are using a "call table" i.e. a table that contains the
actual address for the method. So depending on the class used, this table
has a different content and the method call is directed to the appropriate
code.

Late binding is a different beast. The call is totally revolsed at runtime
i.e. when the code runs you are not even sure that this method exists...
 
1)
On 10-03-2010 14:53, trubar a wrote:

Early binding means that the presence of the member
is checked at compile time. Late binding mean that its checked
at runtime.
Click to expand...

In case of nonvirtual methods, does early binding refer only to
checking for the presence of the member ( aka method ) at compile
time, or also to replacing function call with memory address?

2) Say we have the following code:

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 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 )?


3) Also, I don’t understand how can in the following example the
presence of members be checked during compile time, when compiler
doesn’t even know what type of object will be assigned to reference
variable ‘a’? Granted, compiler knows the name of the method it has to
call, but it won’t know until runtime whether or not variable ‘a’
points to an object derived from B1.Thus, I don’t understand how in
the following example we can claim that calls to a.nonvirtualM and
a.virtualM are resolved at compile time

Assembly assemb = Assembly.Load( “A” );
Type t= assemb.GetType ( “B2” );
B1 a = ( B1 ) Activator.CreateInstance ( “t” );
a.virtualM();
a.nonvirtualM();


Depends on what you mean by resolve.
Click to expand...

By resolved I meant that it is the compiler that replaces function
call a.nonvirtualM() with memory location of that method.
 
In case of nonvirtual methods, does early binding refer only to
checking for the presence of the member ( aka method ) at compile
time, or also to replacing function call with memory address?
Click to expand...

Replacing the function name or relative offset of function
with an absolute memory address is always done at runtime.

(there are a few exceptions, but let us ignore those)
2) Say we have the following code:

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 function calls are replaced with
memory addresses during compilation process.
Click to expand...

They are not.
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 )?
Click to expand...

See above.
3) Also, I don’t understand how can in the following example the
presence of members be checked during compile time, when compiler
doesn’t even know what type of object will be assigned to reference
variable ‘a’? Granted, compiler knows the name of the method it has to
call, but it won’t know until runtime whether or not variable ‘a’
points to an object derived from B1.Thus, I don’t understand how in
the following example we can claim that calls to a.nonvirtualM and
a.virtualM are resolved at compile time

Assembly assemb = Assembly.Load( “A” );
Type t= assemb.GetType ( “B2” );
B1 a = ( B1 ) Activator.CreateInstance ( “t” );
a.virtualM();
a.nonvirtualM();
Click to expand...

You tell the compiler that a can use all methods of B1. So
the compiler checks if the two methods are in B1.

At runtime it will be tested whether B2 can be cast to B1.
By resolved I meant that it is the compiler that replaces function
call a.nonvirtualM() with memory location of that method.
Click to expand...

That is never happening at compile time.

Arne
 
Back
Top