The---of the. NET Framework Source Research series is attributed to the object

After the previous three essays on the. NET Framework Source Research series, I believe we all find that the. NET Framework implementation is actually not complex, perhaps similar to our own project development. I think so. However, after careful and thorough study, We will still find something difficult to notice at ordinary times, and these things to our perfect thinking, broaden our horizons, exercise good coding quality has great significance.

We know. NET all types (including: reference type, value type) are derived from the object class, so that object is the root of all types. So today we are studying the fundamental---System.Object of all elements in. NET (C #).

The object class is very simple in the. NET source code, but it's a total of about 100 lines, and that's one of the lines of code that we have the energy to study carefully. Look at its definition first.

1　　　[Serializable()]
2　　　[ClassInterface(ClassInterfaceType.AutoDual)]
3　　　[System.Runtime.InteropServices.ComVisible(true)]
4　　　public　class　Object

By definition, object seems to be a normal class (is object also derived from object?! ^_^).　 The serializable tag shows that object can be serialized as a serialization deserialization operation. ClassInterface (classinterfacetype.autodual), System.Runtime.InteropServices.ComVisible (true) is. NET is specially designed to support COM. Unless you're wrapping com manually, it doesn't make sense for most of the time to be in managed code.

Next look at its constructor:

1　　　　　[ReliabilityContract(Consistency.WillNotCorruptState,　 Cer.MayFail)]
2　　　　　public　Object(){　}
3　　　　　　　　　[ReliabilityContract(Consistency.WillNotCorruptState,　 Cer.Success)]
4　　　　　　　　~Object()　{}

See from the above code that the object has only one empty method body constructor, which is the origin of the universe, nothing at first. The reliabilitycontract tag is specifically described here. reliabilitycontract defines some code Can be determined by the dependencies between the developer and the developers who depend on the code. This is the official definition that sounds iffy. ReliabilityContract has two properties, two enumerations: CER and consistencyguarantee.cer The behavior of the specified method when invoked within the constrained execution area; Consistencyguarantee refers to the reliability agreement. Looking at MSDN's description of these two enumerations, we found that [ReliabilityContract (Consistency.willnotcorruptstate, Cer.mayfail)] provides security for object, This means that when we call the object constructor, we always know the result of the execution, regardless of whether we encounter an exception.

In addition, object explicitly defines a destructor (another deprecated practice that Microsoft seems to like to do not recommend @_@| |), allowing us to manually release the resources that the object occupies without having to wait until the GC is released automatically.

Specifically, there is a concept we rarely encounter: a CER, a constrained execution area, is part of the mechanism for authoring reliable managed code. A CER defines an area in which the common language runtime (CLR) is constrained and cannot throw Out-of-band exceptions that enable code in the zone not to be fully executed. In this zone, user code is constrained and cannot execute code that causes an Out-of-band exception to be thrown.