Apress Introducing dot NET 4 0 with Visual Studio 2010_1
Số trang: 45
Loại file: pdf
Dung lượng: 1.55 MB
Lượt xem: 11
Lượt tải: 0
Xem trước 5 trang đầu tiên của tài liệu này:
Thông tin tài liệu:
Bạn có thể biết những gì đang xảy ra trong C #, nhưng những gì về điện toán đám mây Azure? Làm thế nào là sẽ ảnh hưởng đến công việc của bạn? Những hạn chế của các cú pháp PLINQ là gì Giới thiệu NET 4.0: với Visual Studio 2010 hướng dẫn bạn thông qua những đổi mới quan trọng và giúp bạn nắm bắt cơ hội mới tự tin và nhanh chóng?
Nội dung trích xuất từ tài liệu:
Apress Introducing dot NET 4 0 with Visual Studio 2010_1 CHAPTER 3 LANGUAGE AND DYNAMIC CHANGES public class TestClass { public void Method1() { } }} Compile the application and examine the IL using ILDASM. You will find something similar to thefollowing:.method private hidebysig static void Main(string[] args) cil managed{ .entrypoint // Code size 15 (0xf) .maxstack 1 .locals init ([0] class Chapter3.DynamicComplex.TestClass t) IL_0000: nop IL_0001: newobj instance void Chapter3.DynamicComplex.TestClass::.ctor() IL_0006: stloc.0 IL_0007: ldloc.0 IL_0008: callvirt instance void Chapter3.DynamicComplex.TestClass::Method1() IL_000d: nop IL_000e: ret} // end of method Program::Main However, if we alter our t v ariable to the following:dynamic t = new TestClass();t.Method1();.. then the IL will look very different (I have removed some of the IL to save some trees):class [mscorlib]System.Collections.Generic.IEnumerable`1) IL_003a: call class [System.Core]System.Runtime.CompilerServices.CallSite`1 class[System.Core]System.Runtime.CompilerServices.CallSite`1::Create(class[System.Core]System.Runtime.CompilerServices.CallSiteBinder) IL_003f: stsfld class [System.Core]System.Runtime.CompilerServices.CallSite`1Chapter3.DynamicComplex.Program/o__SiteContainer0::p__Site1 IL_0056: callvirt instance void class [mscorlib]System.Action`2::Invoke(!0, !1) Whoa, what is happening here? Well the short answer is that calls to dynamic methods are sent tothe Dynamic Language Runtime for resolution. It is time to take a look into how the DLR works. 57 CHAPTER 3 LANGUAGE AND DYNAMIC CHANGES Dynamic Language Runtime (DLR) The Dynamic Language Runtime (DLR) is behind all the cool dynamic functionality and sits just above the core .NET framework. The DLR’s job is basically to resolve calls to dynamic objects, cache dynamic calls making them as quick as possible, and enable interaction between languages by using a common format. The DLR has actually been around a while, and was included in earlier versions of Silverlight. You can even view the source code behind the DLR at: http://dlr.codeplex.com. Note that this version contains a number of features not present in the framework version. When discussing the DLR we need to understand five main concepts: Expression trees/Abstract Syntax Trees (AST) • Dynamic Dispatch • Binders • IDynamicObject • Call Site Caching • Expression/Abstract Syntax Trees (AST) Expression trees are a way of representing code in a tree structure (if you have done any work with LINQ, you may have come across this before with the Expression class). All languages that work with the DLR represent code in the same structure allowing interoperability. Dynamic Dispatch Dynamic Dispatch is the air traffic control center of the DLR, and is responsible for working out what to do with dynamic objects and operations and sending them to the appropriate binder that takes care of the details. Binders Binders resolve classes from dynamic dispatch. .NET 4.0 currently supports the following binder types: Object Binder .NET (uses Reflection and resolved our earlier example to type string) • JavaScript binder (IDynamicObject) • IronPython binder (IDynamicObject) • IronRuby binder (IDynamicObject) • COM binder (IDispatch) • Note that dynamic objects can resolve calls themselves without the DLR’s assistance (if they implement IDynamicObject), and this method will always be used first over the DLR’s dynamic dispatch mechanism.58 CHAPTER 3 LANGUAGE AND DYNAMIC CHANGESIDynamicObjectSometimes you will want objects to carry out resolution themselves, and it is for this purpose theIDynamicObject exists. Normally dynamic objects are processed according to type, but if they implementthe IDynamicObject interface then the object will resolve calls itself. IDynamicObject is used in IronRubyand IronPython.Callsite CachingResolving objects is an expensive operation, so the DLR caches dynamic operations. When a dynamicfunction or operation is performed, the DLR checks to see if it has been called already (Level 0 cache). Ifit hasn’t, then the 10 most recently used dynamic methods for this callsite will be checked ...
Nội dung trích xuất từ tài liệu:
Apress Introducing dot NET 4 0 with Visual Studio 2010_1 CHAPTER 3 LANGUAGE AND DYNAMIC CHANGES public class TestClass { public void Method1() { } }} Compile the application and examine the IL using ILDASM. You will find something similar to thefollowing:.method private hidebysig static void Main(string[] args) cil managed{ .entrypoint // Code size 15 (0xf) .maxstack 1 .locals init ([0] class Chapter3.DynamicComplex.TestClass t) IL_0000: nop IL_0001: newobj instance void Chapter3.DynamicComplex.TestClass::.ctor() IL_0006: stloc.0 IL_0007: ldloc.0 IL_0008: callvirt instance void Chapter3.DynamicComplex.TestClass::Method1() IL_000d: nop IL_000e: ret} // end of method Program::Main However, if we alter our t v ariable to the following:dynamic t = new TestClass();t.Method1();.. then the IL will look very different (I have removed some of the IL to save some trees):class [mscorlib]System.Collections.Generic.IEnumerable`1) IL_003a: call class [System.Core]System.Runtime.CompilerServices.CallSite`1 class[System.Core]System.Runtime.CompilerServices.CallSite`1::Create(class[System.Core]System.Runtime.CompilerServices.CallSiteBinder) IL_003f: stsfld class [System.Core]System.Runtime.CompilerServices.CallSite`1Chapter3.DynamicComplex.Program/o__SiteContainer0::p__Site1 IL_0056: callvirt instance void class [mscorlib]System.Action`2::Invoke(!0, !1) Whoa, what is happening here? Well the short answer is that calls to dynamic methods are sent tothe Dynamic Language Runtime for resolution. It is time to take a look into how the DLR works. 57 CHAPTER 3 LANGUAGE AND DYNAMIC CHANGES Dynamic Language Runtime (DLR) The Dynamic Language Runtime (DLR) is behind all the cool dynamic functionality and sits just above the core .NET framework. The DLR’s job is basically to resolve calls to dynamic objects, cache dynamic calls making them as quick as possible, and enable interaction between languages by using a common format. The DLR has actually been around a while, and was included in earlier versions of Silverlight. You can even view the source code behind the DLR at: http://dlr.codeplex.com. Note that this version contains a number of features not present in the framework version. When discussing the DLR we need to understand five main concepts: Expression trees/Abstract Syntax Trees (AST) • Dynamic Dispatch • Binders • IDynamicObject • Call Site Caching • Expression/Abstract Syntax Trees (AST) Expression trees are a way of representing code in a tree structure (if you have done any work with LINQ, you may have come across this before with the Expression class). All languages that work with the DLR represent code in the same structure allowing interoperability. Dynamic Dispatch Dynamic Dispatch is the air traffic control center of the DLR, and is responsible for working out what to do with dynamic objects and operations and sending them to the appropriate binder that takes care of the details. Binders Binders resolve classes from dynamic dispatch. .NET 4.0 currently supports the following binder types: Object Binder .NET (uses Reflection and resolved our earlier example to type string) • JavaScript binder (IDynamicObject) • IronPython binder (IDynamicObject) • IronRuby binder (IDynamicObject) • COM binder (IDispatch) • Note that dynamic objects can resolve calls themselves without the DLR’s assistance (if they implement IDynamicObject), and this method will always be used first over the DLR’s dynamic dispatch mechanism.58 CHAPTER 3 LANGUAGE AND DYNAMIC CHANGESIDynamicObjectSometimes you will want objects to carry out resolution themselves, and it is for this purpose theIDynamicObject exists. Normally dynamic objects are processed according to type, but if they implementthe IDynamicObject interface then the object will resolve calls itself. IDynamicObject is used in IronRubyand IronPython.Callsite CachingResolving objects is an expensive operation, so the DLR caches dynamic operations. When a dynamicfunction or operation is performed, the DLR checks to see if it has been called already (Level 0 cache). Ifit hasn’t, then the 10 most recently used dynamic methods for this callsite will be checked ...
Tìm kiếm theo từ khóa liên quan:
thủ thuật máy tính tài liệu công nghệ thông tin lập trình máy tính mẹo máy tính cài đặt máy tínhGợi ý tài liệu liên quan:
-
Top 10 mẹo 'đơn giản nhưng hữu ích' trong nhiếp ảnh
11 trang 317 0 0 -
Làm việc với Read Only Domain Controllers
20 trang 305 0 0 -
Thêm chức năng hữu dụng cho menu chuột phải trên Windows
4 trang 290 0 0 -
70 trang 251 1 0
-
Bài giảng Tin học lớp 11 bài 1: Giới thiệu ngôn ngữ lập trình C#
15 trang 238 0 0 -
Tổng hợp lỗi Win 8 và cách sửa
3 trang 234 0 0 -
Sửa lỗi các chức năng quan trọng của Win với ReEnable 2.0 Portable Edition
5 trang 214 0 0 -
Giáo trình Bảo trì hệ thống và cài đặt phần mềm
68 trang 208 0 0 -
Tổng hợp 30 lỗi thương gặp cho những bạn mới sử dụng máy tính
9 trang 205 0 0 -
Phần III: Xử lý sự cố Màn hình xanh
3 trang 204 0 0