Is a call to the following method considered late binding?

Question

1) 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 asemb=Assembly.Load(“A”);
Type t= asemb.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?

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

EDIT:

1)

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

• Yep.

If we have:

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)

The method slot is determined at compile time

I assume that by method slot you’re referring to the entry point in V-table?

Answer 1

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

Considered by whom?

The method slot is determined at compile time. The content of the slot -- the method actually called -- is determined at run time.

Therefore the binding is arguably "late".

Some people say that any binding that doesn't happen fully at compile time is late binding. Some people say that virtual binding that happens partially at compile time and partially at run time still counts as "early", others disagree. I think pretty much everyone agrees that if the slot isn't determined until runtime, it is definitely late binding.

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

Yep.

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

I've never heard "late binding" referring to creation of an instance.

Answer 2

here I’m assuming the address of method a.M will also be at same memory location as "a"

That assumption is incorrect.

If you have

class C { internal int x; public int M() { return this.x; } }

then each instance of C does not get its own copy of the code in M. They all share a single "copy" of the code in M. You don't duplicate what never changes; that would be a waste of memory. When the code is called:

C c = new C();
c.x = 123;
Console.WriteLine(c.M());

then the managed address of c is passed as "this" and control is transferred to the location of the code for M. There's only one "copy" of that code.

The runtime knows where the code for M is because the runtime is what jitted the code, so it knows where it is in memory.

Answer 3

1a) It's early binding

1b) Yes. Like if you change it to a.nonexistentmethod(), you'll get an error

2) Both are late binding.