Reading notes-CLR via C # Chapter 11-13

Objective

This book in the past few years fragmented read two or three times, as a classic book, should repeat read and reread, since I began to write Bo, I am also ready to think of the classic good book reread carefully read it again, and put the notes into the blog, good memory than bad writing, but also in the process can deepen their understanding of the depth, And, of course, sharing it with friends from the technology community.

Event

• The nature of the event
• Private delegate field initialized to null
• Encapsulating Add_event and Remove_event methods
• Accessibility of add_event and remove_event to the accessibility of the event field, including virtual and static adornments
• Coding recommendations for events
• Use virtual void onxxx to define the invocation of an event
• If an object registers a method with an event, the object is not garbage collected. So it's best to unregister the event in Dispose
• Optimization process for event invocation
• if (event!=null) Event (this,e); The problem of linear Cheng state of event variables
• Copy to temp variable, eventhandler<eventargs> temp = Event; if (temp!=null) temp (this, E)
• The above code may be optimized by inline code, so insure a little, consider the next
• eventhandler<eventargs> temp = Interlocked.compareexchange (ref Event, NULL, NULL); if (temp!=null) temp (this, e);
• Trying to delete a method that has never been added, delegate the Remove method does nothing inside
• The Add and Remove methods update a value with a known pattern of thread safety
• The key to implementing the event wrapper manually is to use the container storage key and the delegate list Dictionary<eventkey, delegate> m_events
• Eventhandler<t> in the old version of the T constraint is EventArgs, the new version removes this constraint
• Allow explicit definition of event eventhandler<t> Handler {add {events + = value;} remove{Events-= value;}}
• The event defaults to the execution of the delegate list, and any one delegate exception terminates execution

Generic type

• Static constructors and static fields defined by an open type are not shared between enclosing types
• To mitigate the code explosion, the CLR provides an optimization
• The compiler can be shared when compiling code for a generic type of reference type.
• Value types are not allowed, each value type corresponds to a different JIT-compiled code
• A generic interface can mitigate boxing operations without losing the type of security. such as the iequable generic interface
• Generic constraint struct incompatible nullable type nullable

Covariance and Contravariance

• Covariant and contravariant generic type parameters provide greater flexibility in allocating and using generic types
• With covariant type parameters, you can perform allocations that are very similar to normal polymorphism
• Typically, covariant type parameters can be used as return types for delegates, whereas contravariant type parameters can be used as parameter types
• For an interface, the covariant type parameter can be used as the return type of the interface's method, while the contravariant type parameter can be used as the parameter of the interface's method
• A generic interface or generic delegate type can have both covariant and contravariant type parameters
• Variants do not apply to delegate combinations
• The Func generic delegate (such as Func<t, tresult>) has a covariant return type and a contravariant parameter type. Action generic delegates (such as ACTION<T1, t2>) have contravariant parameter types
• In fact the array (only supports object[] = string[] does not support object[] = int[]. The value type array is not covariant) and the delegate method signature, which already has covariance and contravariance
• These variability can only be applied if the compiler can verify that there is a reference conversion between the types
• Value types do not have this variability because of the need for boxing. Generic types do not have variability for value types
• For methods that use an out or ref keyword for an argument, the variability is not allowed

Interface

• The method that implements the interface must be public
• The CLR defaults to the method as virtual and sealed, and if you explicitly specify virtual, it can be a non-sealed
• Invokes an interface method on an object (called with an object type) that invokes the implementation of the method in the type of the object
• When a value type is transformed into an interface type, boxing occurs
• Explicit interface implementations do not allow the designation of accessibility, which is automatically set to private, and the calling interface method must be made through an interface type variable
• The Eimi method cannot be marked as virtual, so it cannot be overridden because the Eimi method is not really part of the type Object model
• For interface generic constraints, the C # compiler generates specific IL directives that cause an interface method to be called directly on a value type and not boxed
• If interface constraints are not applicable, there is no other way for the compiler to generate these IL directives, so invoking an interface method on a value type always results in boxing
• If you inherit multiple interfaces and the interface has the same name and signature method, you must use an explicit interface method to implement the
• Eimi can only be called through an interface and cannot be called by a derived class. Eimi should be used with caution

Reading notes-CLR via C # Chapter 11-13