|
|
Posted on 7/7/2016 10:15:06 AM
|
|
|
dynamic is a new feature of FrameWork 4.0. The emergence of dynamic has given C# the characteristics of a weak language type. The compiler no longer checks the type at compile time, and the dynamic object supports any feature you want by default during compile time. For example, even if you don't know anything about the object returned by the GetDynamicObject method, you can make a code call like this, and the compiler won't report an error:
When it comes to correct usage, then one wrong usage should be pointed out first:
People often use the keyword var to compare with dynamic. In fact, var and dynamic are completely two concepts and should not be compared together at all. Once compiled, the compile time automatically matches the actual type of the var variable and replaces the variable's declaration with the actual type, which looks as if we are declaring the actual type when encoding. After dynamic is compiled, it is actually an object type, but the compiler will make special treatment of the dynamic type, so that it does not perform any type checking during compilation, but puts the type check in the runtime.
This can be seen in the editor window in Visual Studio. Variables declared as vars support "intelligent sense" because Visual Studio can infer the actual type of var types, while variables declared as dynamic do not support "intelligent sense" because the compiler knows nothing about the type of its runtime. Using Intelligent Sense for dynamic variables prompts "This action will be resolved at runtime".
The fact that the dynamic variable is an object variable can be verified by the IL code, and the IL code will not be posted here. Of course, the compiler also handles dynamic declarations to distinguish between direct object variables.
dynamic is widely rendered in MSDN to simplify interoperability, and I feel that it is based on this that some developers are misunderstood: because many developers do not know how to use coding such as COM+ and OFFICE secondary development, they urgently need a dynamic application reason. So, in daily development, I think dynamic is valuable:
Type conversion
Transitioning between Dynamic type instances and other types of instances is simple, and developers can easily switch between dynmic 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 = System.DateTime.Today;
dynamic d4 = System.Diagnostics.Process.GetProcesses();
Conversely, an implicit conversion can be dynamically applied to any expression of type dynamic.
And vice versa, any expression of type dynamic can also be implicitly converted to other types.
int i = d1;
string str = d2;
DateTime dt = d3;
System.Diagnostics.Process[] procs = d4;
Overload problem with dynamic type parameters in the method
If a method is called passes an object of type dynamic, or the object being called is of type dynamic, then the judgment of overload occurs at runtime and not at compile time.
Dynamic language runtime DLR
The dynamic language runtime is . NET Framework 4 Beta 1 is a new set of APIs that provide support for dynamic types in C# and also implement dynamic programming languages like IronPython and IronRuby.
dynamic simplifies reflections.
Previously we used reflections like this:
Now we have a simplified way to write:
We may be dismissive of 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 are obvious. The compiler optimizes dynamic to be much faster than uncached reflection efficiency. If you have to compare, you can run the code of the above two (the call Add method part) for 1000000 to draw a conclusion.
|
Previous:mvc fetches the JSON XML data for the postNext:A recognition error occurred. near line 1, column 10
|
