dynamic is a new feature of FrameWork 4.0. The emergence of dynamic has given C# the characteristics of weak language types. The compiler no longer checks the type during compilation. The default dynamic object supports any feature you want during compilation. For example, even if you know nothing about the object returned by the GetDynamicObject method, you can call the code like the following, and the compiler will not report an error:
dynamic dynamicObject = GetDynamicObject(); (); (());
Speaking of the correct usage, then the first thing you should point out is an incorrect usage:
People often compare the keyword var with dynamic. In fact, var and dynamic are completely different concepts and should not be put together for comparison. var is actually the "synthetic sugar" thrown to us during the compilation period. Once compiled, the compilation period will automatically match the actual type of the var variable and replace the declaration of the variable with the actual type. This looks like we declare it with the actual type when encoding. After dynamic is compiled, it is actually an object type, but the compiler will specialize in the dynamic type, so that it does not perform any type checks during compilation, but puts the type checks in the runtime.
This can be seen from the editor window of visual studio. Variables declared in var support "intelligent perception" because the visual studio can infer the actual type of the var type, while variables declared in dynamic do not support "intelligent perception" because the compiler knows nothing about the type of its runtime. Using "intelligent perception" for dynamic variables will prompt "This operation will be parsed at runtime".
Regarding the fact that dynamic variable is an object variable, it can be verified through IL code, and IL code will no longer be posted here. Of course, the compiler also handles dynamic declarations to distinguish direct object variables.
Dynamic is widely rendered by MSDN in order to simplify interoperability. I feel that it is based on this that some developers misunderstood: because many developers do not have access to coding such as COM+ and OFFICE secondary development, so they urgently need a reason for applying dynamic. So, in daily development, what I think dynamic is very valuable is:
Type conversion
The conversion between instances of Dynamic type and other types of instances is very simple, and developers can easily switch between dynamic and non-dynamic behaviors. Any instance can be implicitly converted to a dynamic type instance, see the following example:
dynamic d1 = 7; dynamic d2 = "a string"; dynamic d3 = ; dynamic d4 = (); Conversely, an implicit conversion can be dynamically applied to any expression of type dynamic.
Vice versa, any expression of type dynamic can also be implicitly converted to other types.
int i = d1; string str = d2; DateTime dt = d3; [] procs = d4;
Overloading problem with dynamic type parameters in the method
If a method is called, a dynamic type object is passed, or the called object is of dynamic type, then the overloaded judgment occurs at runtime rather than compile time.
Dynamic language runtime DLR
Dynamic Language Runtime is a new set of APIs in .NET Framework 4 Beta 1, which provides support for dynamic types in C# and implements dynamic programming languages like IronPython and IronRuby.
dynamic can simplify reflection.
In the past we used reflection like this:
public class DynamicSample
{
public string Name { get; set; }
public int Add(int a, int b)
{
return a + b;
}
}
DynamicSample dynamicSample = new DynamicSample(); //create instance I did not use reflection to simplify the demonstration.var addMethod = typeof(DynamicSample).GetMethod("Add");
int re = (int)(dynamicSample, new object[] { 1, 2 });
Now, we have a simplified writing method:
dynamic dynamicSample2 = new DynamicSample(); int re2 = (1, 2);
We may disagree with such simplification. After all, it seems that the code has not been reduced much, but if we take into account the two characteristics of efficiency and beauty, then the advantages of dynamic will be revealed. The compiler optimizes dynamic, which is much faster than the reflection without cache. If you have to compare, you can run the code of the above two (called the Add method part) by 1000000 to draw a conclusion.
COM interoperability
C# 4.0 includes multiple features, improving interoperability with traditional COM API interfaces such as Office automation. Dynamic types, named parameters, and optional parameters are also part of the improvement.
Many COM methods allow their parameters and return value types to be object, so for strongly typed languages such as C#, a lot of casting is required. However, in C# 4.0, if the /link option is added at compile time, the dynamic type will have a new effect: it makes the object type (parameter type or return type) in the COM interface method signature be regarded as dynamic, thus avoiding a lot of type conversion work. For example, the following statement compares this.
// No use dynamic.(()[1, 1]).Value2 = "Name"; range = ()[1, 1]; // Use dynamic,[1, 1].Value = "Name"; range = [1, 1];
The above is the correct usage of dynamic keywords in C# that the editor introduced to you (recommended). I hope it will be helpful to everyone. If you have any questions, please leave me a message and the editor will reply to everyone in time. Thank you very much for your support for my website!