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?
Late Binding
With late binding all you have is the name of the method. At compile time you have no way of known if the method even exists. This is known as "duck typing" in languages such as Ruby or Python.
Late binding is slow because you have to look up the function by name. It is also dangerous because you are not protected from minor spelling errors.
Prior to version 4, C# has no support for late binding aside from explicitly calling the reflection API.
Early Binding
When using early binding you compile against an actual method. This method may be referred to directly or it may be a slot in a V-table. Either way you are garunteed to not throw a MissingMethod exception.
History
Visual Basic was well known for supporting both early and late binding, but due it its other limitations it was never considered a true dynamic language. At the same time, versions prior to 7 (a.k.a. VB.NET) had very poor support for enforcing early binding, making it hard to call it a static language either.
With .NET 4, both C# and VB can be said to offer most features expected of both static and dynamically typed languages.
At one point Java was mistakenly said to have late binding support when it fact it only had early bound, OOP style V-tables. This has caused quite a bit on confusion over the years.
Virtual methods are early bound when the compiler knows the exact type at compile time.
If the compiler does not have the exact type it will generate a vtable lookup style late binding instead.
A call to a virtual method may be early bound as Joshua explains (i.e. the compiler can see the exact type of the object, no polymorphism going on), or it may be made through a v-table.
C# only does late binding when you use reflection (and in the next version, there's a new "dynamic" keyword to request late binding).
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.
EDIT to address new questions:
In (1) the entire premise is false. Functions aren't stored anywhere near the objects that "own" them. In fact, there's only one copy of the function for the entire program, and the object instance is passed as a hidden "this" parameter so the function knows which instance is being addressed.
For (2), there are two possibilities. One, the function call is done through reflection via a MethodInfo or such. This is truly late-bound. Two, the function call is made through an interface or base class which the caller knows at compile-time, even though the total type of the object isn't known. In this case a v-table call is used because the layout of the v-table is determined by the base class or interface, so the caller knows it and can predetermine the offset into the v-table.
Related
Specifically, I am attempting to create a method that takes in a lambda expression and then spins that expression off as the main method of a temporary console application at run time in order to allow for spinning off small sections of code as a separate process at run-time so I can better isolate the memory behavior (I did look into application domains but ran into other problems there due to certain limitations for my use case). Sort of a really limited fork.
This is relatively straightforward if it can be assumed that the lambda expression contains only local variables, but I am struggling with figuring out just how much I'll have to do (and how the best way to go about it is) if the expression also makes use of non-local variables (that is, a variable that exists within the enclosing scope, as per the comment below. I couldn't think of a better way at the time to phrase "a variable that is not within the local scope but is accessible").
To my knowledge, a non-local variable means a field load instruction of some sort will be generated within the MSIL. While I can potentially make a copy of the required objects/fields in the secondary application, if I try to take the MSIL of the lambda expression as-is via MethodBody.GetILAsByteArray(), then the generated code (I believe) will contain field load instructions that will be targeting metadata table entries that may (most likely will be) different than the metadata table entries for the copies of those objects/fields created in the console application via Reflection.Emit.
Further complicating this is the matter that closure, which I think/if I remember correctly means that any non-local reference within the lambda expression body will cause an object to be created that will hold the values (copies? references? I don't quite recall). I probably don't need to worry about that though, because it won't actually be a lambda expression once it is emitted as that second application in my particular use case? If I'm just getting the method body, I think I'd end up sidestepping the usual handling for closure?
Ultimately I have two questions:
A. Is there anything I'm missing in my general understanding of how this whole process will work
B. Will I have to go and just field table references in the MSIL and if so, what would be the most pragmatic way to go about this? Is there any way to get Reflection.Emit to make these adjustments for me?
Of course, I'd be happy to hear if there is some much less frustrating way to accomplish what I am attempting to do and am open to any suggestions.
Accessing local variables outside an anonymous method/lambda expression creates a closure object holding the variables. Assuming you pass the lambda as a delegate, the Target property will contain the outside state of the delegate (something like DisplayClass). Unless you modify the CIL of the method, you won't get real-time communication via this class from the remote process, but you can simply serialize it and pass it to the remote process. Of course, if the delegate depends on static fields, you are left with analyzing the method to find them and serialize them (using System.Linq.Expressions will be helpful).
Now, if the remote process references the main assembly, it will find the DisplayClass there, but if not, you will have to serialize even its type and build it on the other side, hooking it with the method using AppDomain.TypeResolve. Then you can deserialize the object with the created type.
First off, sorry for the probably confusing title, feel free to change it whenever somebody knows a more appropriate one.
I'm in the process of porting a math library from C++ to C#. Porting the actual code was done in a couple of days. However, I've been struggling to solve all the bugs introduced by the fact that C# classes are reference types versus C++ classes being value types.
Let me explain: If I have a Class Foo in C++ that has nested class Bar, and if I assign an existing instance of Bar to Foo, I'm essentially copying it, if the C++ compiler knows a way to do so (IF I'm not using pointers, of course)
If I do the same in C# I assign a reference. This leads to incredibly hard to find side effects. If, in C#, my code later modifies my Bar instance after assigning it to Foo, then of course the Foo.Bar objects gets modified as well. Not good.
So my question is: Is there an easy way, or a best practice approach, to find the positions in my code that assign a reference when I was assuming I assigned a copy? I even considered creating a new object every time the getter is called on an object, and copying the values there. Of course this would mean that I can never have a reverence to an object again. Again, not good.
So basically what I'm asking is: How can I find every occurrence of the assign operator (=) where the TARGET is a reference type? It's those lines of code I need to change.
I've tried to do it manually by simply searching for the '=' character, but after searching thousands and thousands lines of code, but I'm still missing the occasional assignment target.
You should look into the struct feature of C# instead of class. Structs are value types.
I have an application where I have a method taking a PropertyInfo parameter and would like to call this method from IL. For similar methods taking a MethodInfo, for example, I can create an intermediate method taking a RuntimeMethodHandle and use GetMethodFromHandle. The IL can then use Ldtoken to pass the handle.
However, there does not appear to be an equivalent metadata token for properties. I can see why this might be the case (since properties are really just a way of bundling methods together and never 'called' from IL), but there is definitely property metadata associated with the type. I have access to this property metadata at Emit-time, so I'd like a way to be able to pass this directly without having to resort to Reflection by name at runtime (i.e. emit Reflection calls to GetProperty taking a string that will execute at runtime.) Is there a way to do this?
Per a request in the comments, here is the application:
I'm creating an adaptor class that exposes a property reference as its component bits via a bool this[int index] property. My application compiles PLC code to a .NET assembly and so I'm trying to create diagnostic accessors that approximate the easy bitwise access provided by the PLC (where you write MyTag.2 to indicate bit 2 of tag MyTag.) This syntax can't be used for consumption by C#, but PLC.GetBits().MyTag[2] is a reasonable approximation.
My original approach was implemented using PropertyInfo (which is how I encountered this issue), but I can certainly work around it by passing the applicable metadata from the PropertyInfo as multiple parameters. I was mainly just curious to see if it was possible to pass the PropertyInfo directly, since I hadn't ever run into this before.
No, I don't think you can. I say this in part through familiarity with that API, and in part because the Expression compiler in the C# compiler still uses reflection when it refers to a PropertyInfo, but uses more direct methods (ldtoken etc) when referring to types and methods (for example, a getter/setter). I suspect the C# compiler team would have used it if it existed.
However, in most common IL-emit scenarios, it is not necessary to pass around a PropertyInfo. options:
use MethodBase to get the getter or setter (methods can be fetched by token), and infer the property by name (not 100% robust, but should usually work)
pass around the name instead (ldstr)
Refer to Ecma-335, Partition I, 8.10.3 Property and event inheritance
Fundamentally, properties and events are constructs of the metadata intended for use by tools
that target the CLI and are not directly supported by the VES itself. Therefore, it is the job of the
source language compiler and the reflection library (see Partition IV – Kernel Package) to
determine rules for name hiding, inheritance, and so forth. The source compiler shall generate
CIL that directly accesses the methods named by the events and properties, not the events or
properties themselves.
Ecma-335, Partition I, 8.11.3 Property definitions
A property definition is always part of either an interface definition or a class definition. The
name and value of a property definition is scoped to the type that includes the property
definition. The CTS requires that the method contracts that comprise the property shall match the
method implementations, as with any other method contract. There are no CIL instructions
associated with properties, just metadata.
There is a well-known fact that C++ templates are turing-complete, CSS is turing-complete (!) and that the C# overload resolution is NP-hard (even without generics).
But is C# 4.0 (with co/contravariance, generics etc) compile-time turing complete?
Unlike templates in C++, generics in C# (and other .net lang) are a runtime generated feature. The compiler does do some checking as to verify the types use but, actual substitution happens at runtime. Same goes for Co and contravariance if I'm not mistaken as well as even the preprocessor directives. Lots of CLR magic.
(At the implementation level, the primary difference is that C#
generic type substitutions are performed at runtime and generic type
information is thereby preserved for instantiated objects)
See MSDN
http://msdn.microsoft.com/en-us/library/c6cyy67b(v=vs.110).aspx
Update:
The CLR does preform type checking via information stored in the metadata associated with the compiled assemblies(Vis-à-vis Jit Compliation), It does this as one of its many services,(ShuggyCoUk answer on this question explains it in detail) (others include memory management and exception handling). So with that I would infer that the compiler has a understanding of state as progression and state as in machine internal state (TC,in part, mean being able to review data (symbols) with so reference to previous data(symbols) , conditionally and evaluate) (I hesitated to state the exact def of TC as I, myself am not sure I have it fully grasped, so feel free to fill in the blanks and correct me when applicable ) So with that I would say with a bit of trepidation, yes, yes it can be.
Can anyone explain to me run-time polymorphism and compile time polymorphism with respect to C#?
I have found similar questions on SO but they were regarding C++.
Here is a site with a good explanation:
http://www.dickbaldwin.com/csharp/Cs000120.htm
To quote the article:
The reason that this type of polymorphism is often referred to as runtime polymorphism is because the decision as to which version of the method to execute cannot be made until runtime. The decision cannot be made at compile time (as is the case with overloaded methods).
The decision cannot be made at compile time because the compiler has no way of knowing (when the program is compiled) the actual type of the object whose reference will be stored in the reference variable.
In an extreme case, for example, the object might be obtained at runtime from a network connection of which the compiler has no knowledge.