BCL mscorlib [00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 ] 1.0.5000.0 2.0.0.0 4.0.0.0 All public static members of this type are safe for multithreaded operations. No instance members are guaranteed to be thread safe. System.Runtime.InteropServices.ClassInterface(System.Runtime.InteropServices.ClassInterfaceType.AutoDual) System.Runtime.InteropServices.ComVisible(true)

Languages typically do not require a class to declare inheritance from because the inheritance is implicit.

Because all classes in the .NET Framework are derived from , every method defined in the class is available in all objects in the system. Derived classes can and do override some of these methods, including:

- Supports comparisons between objects.

- Performs cleanup operations before an object is automatically reclaimed.

- Generates a number corresponding to the value of the object to support the use of a hash table.

- Manufactures a human-readable text string that describes an instance of the class.

## Performance Considerations

If you are designing a class, such as a collection, that must handle any type of object, you can create class members that accept instances of the class. However, the process of boxing and unboxing a type carries a performance cost. If you know your new class will frequently handle certain value types you can use one of two tactics to minimize the cost of boxing.

Create a general method that accepts an type, and a set of type-specific method overloads that accept each value type you expect your class to frequently handle. If a type-specific method exists that accepts the calling parameter type, no boxing occurs and the type-specific method is invoked. If there is no method argument that matches the calling parameter type, the parameter is boxed and the general method is invoked.

Design your type and its members to use generics. The common language runtime creates a closed generic type when you create an instance of your class and specify a generic type argument. The generic method is type-specific and can be invoked without boxing the calling parameter.

Although it is sometimes necessary to develop general purpose classes that accept and return types, you can improve performance by also providing a type-specific class to handle a frequently used type. For example, providing a class that is specific to setting and getting Boolean values eliminates the cost of boxing and unboxing Boolean values.

Supports all classes in the .NET Framework class hierarchy and provides low-level services to derived classes. This is the ultimate base class of all classes in the .NET Framework; it is the root of the type hierarchy.

- Constructor
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Runtime.ConstrainedExecution.ReliabilityContract(System.Runtime.ConstrainedExecution.Consistency.WillNotCorruptState, System.Runtime.ConstrainedExecution.Cer.MayFail)

  This constructor is called by constructors in derived classes, but it can also be used to directly create an instance of the class.

  Initializes a new instance of the class.

  0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Boolean ``

  The following example contains two calls to the default implementation of .

  `using System; class MyClass { static void Main() { Object obj1 = new Object(); Object obj2 = new Object(); Console.WriteLine(obj1.Equals(obj2)); obj1 = obj2; Console.WriteLine(obj1.Equals(obj2)); } }`

  The output is

  False

  True

  The following example shows a class that overrides the method to provide value equality and a class , which is derived from . Because Point's override of is the first in the inheritance chain to introduce value equality, the method of the base class (which is inherited from and checks for referential equality) is not invoked. However, invokes because implements in a manner that provides value equality.

  `using System; public class Point: object { int x, y; public override bool Equals(Object obj) { //Check for null and compare run-time types. if (obj == null || GetType() != obj.GetType()) return false; Point p = (Point)obj; return (x == p.x) && (y == p.y); } public override int GetHashCode() { return x ^ y; } } class Point3D: Point { int z; public override bool Equals(Object obj) { return base.Equals(obj) && z == ((Point3D)obj).z; } public override int GetHashCode() { return base.GetHashCode() ^ z; } }`

  The method checks that the argument is non-null and that it references an instance of the same type as this object. If either of those checks fail, the method returns false. The method uses to determine whether the run-time types of the two objects are identical. (Note that is not used here because it returns the static type.) If instead the method had used a check of the form is Point , the check would return true in cases where is an instance of a subclass of , even though and the current instance are not of the same runtime type. Having verified that both objects are of the same type, the method casts to type and returns the result of comparing the instance variables of the two objects.

  In , the inherited method is invoked before anything else is done; the inherited method checks to see that is non-null, that is an instance of the same class as this object, and that the inherited instance variables match. Only when the inherited returns true does the method compare the instance variables introduced in the subclass. Specifically, the cast to is not executed unless has been determined to be of type or a subclass of .

  In the previous example, operator == (the equality operator) is used to compare the individual instance variables. In some cases, it is appropriate to use the method to compare instance variables in an implementation, as shown in the following example:

  `using System; class Rectangle { Point a, b; public override bool Equals(Object obj) { if (obj == null || GetType() != obj.GetType()) return false; Rectangle r = (Rectangle)obj; //Use Equals to compare instance variables return a.Equals(r.a) && b.Equals(r.b); } public override int GetHashCode() { return a.GetHashCode() ^ b.GetHashCode(); } }`

  In some languages, such as C#, operator overloading is supported. When a type overloads operator ==, it should also override the method to provide the same functionality. This is typically accomplished by writing the method in terms of the overloaded operator ==. For example:

  `using System; public struct Complex { double re, im; public override bool Equals(Object obj) { return obj is Complex && this == (Complex)obj; } public override int GetHashCode() { return re.GetHashCode() ^ im.GetHashCode(); } public static bool operator ==(Complex x, Complex y) { return x.re == y.re && x.im == y.im; } public static bool operator !=(Complex x, Complex y) { return !(x == y); } }`

  Because Complex is a C# struct (a value type), it is known that there will be no subclasses of . Therefore, the method need not compare the GetType() results for each object, but can instead use the operator to check the type of the parameter.

  The type of comparison between the current instance and the parameter depends on whether the current instance is a reference type or a value type.

  If the current instance is a reference type, the method tests for reference equality, and a call to the method is equivalent to a call to the method. Reference equality means that the object variables that are compared refer to the same object. The following example illustrates the result of such a comparison. It defines a Person class, which is a reference type, and calls the Person class constructor to instantiate two new Person objects, person1a and person2, which have the same value. It also assigns person1a to another object variable, person1b. As the output from the example shows, person1a and person1b are equal because they reference the same object. However, person1a and person2 are not equal, although they have the same value.

  code reference: System.Object.Equals#2

  If the current instance is a value type, the method tests for value equality. Value equality means the following:

  The two objects are of the same type. As the following example shows, a object that has a value of 12 does not equal an object that has a value of 12, because the two objects have different run-time types.

  code reference: System.Object.Equals#3

  The values of the public and private fields of the two objects are equal. The following example tests for value equality. It defines a Person structure, which is a value type, and calls the Person class constructor to instantiate two new Person objects, person1 and person2, which have the same value. As the output from the example shows, although the two object variables refer to different objects, person1 and person2 are equal because they have the same value for the private personName field.

  code reference: System.Object.Equals#4

  Because the class is the base class for all types in the .NET Framework, the method provides the default equality comparison for all other types. However, types often override the method to implement value equality. For more information, see the Notes for Callers and Notes for Inheritors sections.

  ## Notes for the wrt

  When you call the method overload on a class in the wrt, it provides the default behavior for classes that don’t override . This is part of the support that the .NET Framework provides for the wrt (see .NET Framework Support for Windows Store Apps and Windows Runtime). Classes in the wrt don’t inherit , and currently don’t implement an method. However, they appear to have , , and methods when you use them in your C# or Visual Basic code, and the .NET Framework provides the default behavior for these methods.

  wrt classes that are written in C# or Visual Basic can override the method overload.

  ## Notes for Callers

  Derived classes frequently override the method to implement value equality. In addition, types also frequently provide an additional strongly typed overload to the Equals method, typically by implementing the interface. When you call the Equals method to test for equality, you should know whether the current instance overrides and understand how a particular call to an Equals method is resolved. Otherwise, you may be performing a test for equality that is different from what you intended, and the method may return an unexpected value.

  The following example provides an illustration. It instantiates three objects with identical strings, and then makes four calls to Equals methods. The first method call returns true, and the remaining three return false.

  code reference: System.Object.Equals#5

  In the first case, the strongly typed method overload, which tests for value equality, is called. Because the strings assigned to the two objects are equal, the method returns true. However, does not override . Because of this, when the object is cast to an , when a instance is assigned to a variable of type , and when the method is passed two objects, the default method is called. Because is a reference type, this is equivalent to passing the two objects to the method. Although all three objects contain identical strings, they refer to three distinct objects. As a result, these three method calls return false.

  You can compare the current object to another object for reference equality by calling the method. In Visual Basic, you can also use the is keyword (for example, If Me Is otherObject Then ...).

  ## Notes for Inheritors

  When you define your own type, that type inherits the functionality defined by the Equals method of its base type. The following table lists the default implementation of the Equals method for the major categories of types in the .NET Framework.

  Type category

  Equality defined by

  Comments

  Class derived directly from

  Reference equality; equivalent to calling .

  Structure

  Value equality; either direct byte-by-byte comparison or field-by-field comparison using reflection.

  Enumeration

  Values must have the same enumeration type and the same underlying value.

  Delegate

  Delegates must have the same type with identical invocation lists.

  Interface

  Reference equality.

  For a value type, you should always override , because tests for equality that rely on reflection offer poor performance. You can also override the default implementation of for reference types to test for value equality instead of reference equality and to define the precise meaning of value equality. Such implementations of return true if the two objects have the same value, even if they are not the same instance. The type's implementer decides what constitutes an object's value, but it is typically some or all the data stored in the instance variables of the object. For example, the value of a object is based on the characters of the string; the method overrides the method to return true for any two string instances that contain the same characters in the same order.

  The following example shows how to override the method to test for value equality. It overrides the method for the Person class. If Person accepted its base class implementation of equality, two Person objects would be equal only if they referenced a single object. However, in this case, two Person objects are equal if they have the same value for the Person.Id property.

  code reference: System.Object.Equals#6

  In addition to overriding , you can implement the interface to provide a strongly typed test for equality.

  The following statements must be true for all implementations of the method. In the list, x, y, and z represent object references that are not null.

  x.Equals(x) returns true, except in cases that involve floating-point types. See ISO/IEC/IEEE 60559:2011, Information technology -- Microprocessor Systems -- Floating-Point arithmetic.

  x.Equals(y) returns the same value as y.Equals(x).

  x.Equals(y) returns true if both x and y are NaN.

  If (x.Equals(y) && y.Equals(z)) returns true, then x.Equals(z) returns true.

  Successive calls to x.Equals(y) return the same value as long as the objects referenced by x and y are not modified.

  x.Equals(null) returns false.

  Implementations of must not throw exceptions; they should always return a value. For example, if is null, the method should return false instead of throwing an .

  Follow these guidelines when overriding :

  Types that implement must override .

  Types that override must also override ; otherwise, hash tables might not work correctly.

  You should consider implementing the interface to support strongly typed tests for equality. Your implementation should return results that are consistent with .

  If your programming language supports operator overloading and you overload the equality operator for a given type, you must also override the method to return the same result as the equality operator. This helps ensure that class library code that uses (such as and ) behaves in a manner that is consistent with the way the equality operator is used by application code.

  ## Guidelines for Reference Types

  The following guidelines apply to overriding for a reference type:

  Consider overriding if the semantics of the type are based on the fact that the type represents some value(s).

  Most reference types must not overload the equality operator, even if they override . However, if you are implementing a reference type that is intended to have value semantics, such as a complex number type, you must override the equality operator.

  You should not override on a mutable reference type. This is because overriding requires that you also override the method, as discussed in the previous section. This means that the hash code of an instance of a mutable reference type can change during its lifetime, which can cause the object to be lost in a hash table.

  ## Guidelines for Value Types

  The following guidelines apply to overriding for a value type:

  If you are defining a value type that includes one or more fields whose values are reference types, you should override . The implementation provided by performs a byte-by-byte comparison for value types whose fields are all value types, but it uses reflection to perform a field-by-field comparison of value types whose fields include reference types.

  If you override and your development language supports operator overloading, you must overload the equality operator.

  You should implement the interface. Calling the strongly typed method avoids boxing the argument.

  Determines whether the specified object is equal to the current object.

  true if the specified object is equal to the current object; otherwise, false.

  The object to compare with the current object. 0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Boolean `` ``

  The following example demonstrates the method.

  `using System; public class MyClass { public static void Main() { string s1 = "Tom"; string s2 = "Carol"; Console.WriteLine("Object.Equals(\"{0}\", \"{1}\") => {2}", s1, s2, Object.Equals(s1, s2)); s1 = "Tom"; s2 = "Tom"; Console.WriteLine("Object.Equals(\"{0}\", \"{1}\") => {2}", s1, s2, Object.Equals(s1, s2)); s1 = null; s2 = "Tom"; Console.WriteLine("Object.Equals(null, \"{1}\") => {2}", s1, s2, Object.Equals(s1, s2)); s1 = "Carol"; s2 = null; Console.WriteLine("Object.Equals(\"{0}\", null) => {2}", s1, s2, Object.Equals(s1, s2)); s1 = null; s2 = null; Console.WriteLine("Object.Equals(null, null) => {2}", s1, s2, Object.Equals(s1, s2)); } }`

  The output is

  Object.Equals("Tom", "Carol") => False

  Object.Equals("Tom", "Tom") => True

  Object.Equals(null, "Tom") => False

  Object.Equals("Carol", null) => False

  Object.Equals(null, null) => True

  The static method indicates whether two objects, and , are equal. It also enables you to test objects whose value is null for equality. It compares and for equality as follows:

  It determines whether the two objects represent the same object reference. If they do, the method returns true. This test is equivalent to calling the method. In addition, if both and are null, the method returns true.

  It determines whether either or is null. If so, it returns false.

  If the two objects do not represent the same object reference and neither is null, it calls .Equals() and returns the result. This means that if overrides the method, this override is called.

  Determines whether the specified object instances are considered equal.

  true if the objects are considered equal; otherwise, false. If both and are null, the method returns true.

  The first object to compare. The second object to compare. 0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Runtime.ConstrainedExecution.ReliabilityContract(System.Runtime.ConstrainedExecution.Consistency.WillNotCorruptState, System.Runtime.ConstrainedExecution.Cer.Success)
  System.Void

  The method is used to perform cleanup operations on unmanaged resources held by the current object before the object is destroyed. The method is protected and therefore is accessible only through this class or through a derived class.

  In this section:

  How finalization works

  Notes for implementers

  The SafeHandle alternative

  ## How finalization works

  The class provides no implementation for the method, and the garbage collector does not mark types derived from for finalization unless they override the method.

  If a type does override the method, the garbage collector adds an entry for each instance of the type to an internal structure called the finalization queue. The finalization queue contains entries for all the objects in the managed heap whose finalization code must run before the garbage collector can reclaim their memory. The garbage collector then calls the method automatically under the following conditions:

  After an object becomes inaccessible, unless the object has been exempted from finalization by a call to the method.

  During shutdown of an application domain, unless the object is exempt from finalization. During shutdown, even objects that are still accessible are finalized.

  is automatically called only once on a given instance, unless the object is re-registered by using a mechanism such as and the method has not been subsequently called.

  operations have the following limitations:

  The exact time when the finalizer executes during garbage collection is undefined. To ensure deterministic release of resources for instances of your class, implement a Close method or provide a implementation.

  The finalizers of two objects are not guaranteed to run in any specific order, even if one object refers to the other. That is, if Object A has a reference to Object B and both have finalizers, Object B might have already been finalized when the finalizer of Object A starts.

  The thread on which the finalizer runs is unspecified.

  The method might not run to completion or might not run at all under the following exceptional circumstances:

  If another finalizer blocks indefinitely (goes into an infinite loop, tries to obtain a lock it can never obtain, and so on). Because the runtime tries to run finalizers to completion, other finalizers might not be called if a finalizer blocks indefinitely.

  If the process terminates without giving the runtime a chance to clean up. In this case, the runtime's first notification of process termination is a DLL_PROCESS_DETACH notification.

  The runtime continues to finalize objects during shutdown only while the number of finalizable objects continues to decrease.

  If or an override of throws an exception, and the runtime is not hosted by an application that overrides the default policy, the runtime terminates the process and no active try/finally blocks or finalizers are executed. This behavior ensures process integrity if the finalizer cannot free or destroy resources.

  ## Notes for implementers

  You should override for a class that uses unmanaged resources such as file handles or database connections that must be released when the managed object that uses them is discarded during garbage collection.

  If a object is available that wraps your unmanaged resource, the recommended alternative is to implement the dispose pattern with a safe handle and not override . For more information, see The SafeHandle alternative section.

  The method does nothing by default, but you should override only if necessary, and only to release unmanaged resources. Reclaiming memory during garbage collection tends to take much longer if a finalization operation runs, because it requires at least two garbage collections. In addition, you should override the method for reference types only. The common language runtime only finalizes reference types. It ignores finalizers on value types.

  Every implementation of in a derived type must call its base type's implementation of . This is the only case in which application code is allowed to call .

  The C# compiler does not allow you to override the method. Instead, you provide a finalizer by implementing a destructor for your class. A C# destructor automatically calls the destructor of its base class.

  Visual C++ also provides its own syntax for implementing the method. For more information, see the "Destructors and finalizers" section of How to: Define and Consume Classes and Structs (C++/CLI).

  Because garbage collection is non-deterministic, you do not know precisely when the garbage collector performs finalization. To release resources immediately, you can also choose to implement the dispose pattern and the interface. The implementation can be called by consumers of your class to free unmanaged resources, and you can use the method to free unmanaged resources in the event that the method is not called.

  can take almost any action, including resurrecting an object (that is, making the object accessible again) after it has been cleaned up during garbage collection. However, the object can only be resurrected once; cannot be called on resurrected objects during garbage collection. There is one action that your implementation of should never take: it should never throw an exception.

  ## The SafeHandle alternative

  Creating reliable finalizers is often difficult, because you cannot make assumptions about the state of your application, and because unhandled system exceptions such as and terminate the finalizer. Instead of implementing a finalizer for your class to release unmanaged resources, you can use an object that is derived from the class to wrap your unmanaged resources, and then implement the dispose pattern without a finalizer. The .NET Framework provides the following classes in the namespace that are derived from :

  is a wrapper class for a file handle.

  is a wrapper class for memory-mapped file handles.

  is a wrapper class for a pointer to a block of unmanaged memory.

  , , and are wrapper classes for cryptographic handles.

  is a wrapper class for pipe handles.

  is a wrapper class for a handle to a registry key.

  is a wrapper class for a wait handle.

  The following example uses the dispose pattern with safe handles instead of overriding the method. It defines a FileAssociation class that wraps registry information about the application that handles files with a particular file extension. The two registry handles returned as out parameters by Windows RegOpenKeyEx function calls are passed to the constructor. The type's protected Dispose method then calls the SafeRegistryHandle.Dispose method to free these two handles.

  code reference: System.Object.Finalize#2

  Allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection.

  0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Int32

  In some cases, is implemented to simply return an integer value. The following example illustrates an implementation of , which returns an integer value:

  `using System; public struct Int32 { int value; //other methods... public override int GetHashCode() { return value; } }`

  Frequently, a type has multiple data members that can participate in generating the hash code. One way to generate a hash code is to combine these fields using an xor (exclusive or) operation, as shown in the following example:

  `using System; public struct Point { int x; int y; //other methods public override int GetHashCode() { return x ^ y; } }`

  The following example illustrates another case where the type's fields are combined using xor (exclusive or) to generate the hash code. Notice that in this example, the fields represent user-defined types, each of which implements (and should implement as well):

  `using System; public class SomeType { public override int GetHashCode() { return 0; } } public class AnotherType { public override int GetHashCode() { return 1; } } public class LastType { public override int GetHashCode() { return 2; } } public class MyClass { SomeType a = new SomeType(); AnotherType b = new AnotherType(); LastType c = new LastType(); public override int GetHashCode () { return a.GetHashCode() ^ b.GetHashCode() ^ c.GetHashCode(); } }`

  Avoid implementing in a manner that results in circular references. In other words, if AClass.GetHashCode calls BClass.GetHashCode, it should not be the case that BClass.GetHashCode calls AClass.GetHashCode.

  In some cases, the data member of the class in which you are implementing is bigger than a . In such cases, you could combine the high order bits of the value with the low order bits using an XOR operation, as shown in the following example:

  `using System; public struct Int64 { long value; //other methods... public override int GetHashCode() { return ((int)value ^ (int)(value >> 32)); } }`

  A hash code is a numeric value that is used to insert and identify an object in a hash-based collection such as the class, the class, or a type derived from the class. The method provides this hash code for algorithms that need quick checks of object equality.

  For information about how hash codes are used in hash tables and for some additional hash code algorithms, see the Hash Function entry in Wikipedia.

  Two objects that are equal return hash codes that are equal. However, the reverse is not true: equal hash codes do not imply object equality, because different (unequal) objects can have identical hash codes. Furthermore, the .NET Framework does not guarantee the default implementation of the method, and the value this method returns may differ between .NET Framework versions and platforms, such as 32-bit and 64-bit platforms. For these reasons, do not use the default implementation of this method as a unique object identifier for hashing purposes. Two consequences follow from this:

  You should not assume that equal hash codes imply object equality.

  You should never persist or use a hash code outside the application domain in which it was created, because the same object may hash across application domains, processes, and platforms.

  A hash code is intended for efficient insertion and lookup in collections that are based on a hash table. A hash code is not a permanent value. For this reason:

  Do not serialize hash code values or store them in databases.

  Do not use the hash code as the key to retrieve an object from a keyed collection.

  Do not send hash codes across application domains or processes. In some cases, hash codes may be computed on a per-process or per-application domain basis.

  Do not use the hash code instead of a value returned by a cryptographic hashing function if you need a cryptographically strong hash. For cryptographic hashes, use a class derived from the or class.

  Do not test for equality of hash codes to determine whether two objects are equal. (Unequal objects can have identical hash codes.) To test for equality, call the or method.

  The method can be overridden by a derived type. If is not overridden, hash codes for reference types are computed by calling the method of the base class, which computes a hash code based on an object's reference; for more information, see . In other words, two objects for which the method returns true have identical hash codes. If value types do not override , the method of the base class uses reflection to compute the hash code based on the values of the type's fields. In other words, value types whose fields have equal values have equal hash codes. For more information about overriding , see the "Notes to Inheritors" section.

  If you override the method, you should also override , and vice versa. If your overridden method returns true when two objects are tested for equality, your overridden method must return the same value for the two objects.

  If an object that is used as a key in a hash table does not provide a useful implementation of , you can specify a hash code provider by supplying an implementation to one of the overloads of the class constructor.

  ## Notes for the wrt

  When you call the method on a class in the wrt, it provides the default behavior for classes that don’t override . This is part of the support that the .NET Framework provides for the wrt (see .NET Framework Support for Windows Store Apps and Windows Runtime). Classes in the wrt don’t inherit , and currently don’t implement a . However, they appear to have , , and methods when you use them in your C# or Visual Basic code, and the .NET Framework provides the default behavior for these methods.

  wrt classes that are written in C# or Visual Basic can override the method.

  Serves as the default hash function.

  A hash code for the current object.

  0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Type

  The following example demonstrates the fact that returns the run-time type of the current instance:

  `using System; public class MyBaseClass: Object { } public class MyDerivedClass: MyBaseClass { } public class Test { public static void Main() { MyBaseClass myBase = new MyBaseClass(); MyDerivedClass myDerived = new MyDerivedClass(); object o = myDerived; MyBaseClass b = myDerived; Console.WriteLine("mybase: Type is {0}", myBase.GetType()); Console.WriteLine("myDerived: Type is {0}", myDerived.GetType()); Console.WriteLine("object o = myDerived: Type is {0}", o.GetType()); Console.WriteLine("MyBaseClass b = myDerived: Type is {0}", b.GetType()); } }`

  The output is

  mybase: Type is MyBaseClass

  myDerived: Type is MyDerivedClass

  object o = myDerived: Type is MyDerivedClass

  MyBaseClass b = myDerived: Type is MyDerivedClass

  For two objects and that have identical runtime types, Object.ReferenceEquals(x.GetType(),y.GetType()) returns true. The following example uses the method with the method to determine whether one numeric value is the same type as two other numeric values.

  code reference: System.Object.GetType#1

  To determine whether an object is a specific type, you can use your language's type comparison keyword or construct. For example, you can use the TypeOf…Is construct in Visual Basic or the is keyword in C#.

  The object exposes the metadata associated with the class of the current .

  Gets the of the current instance.

  The exact runtime type of the current instance.

  0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Object

  The following example shows a class called as well as a representation of the instance of returned by .

  `using System; class MyBaseClass { public static string CompanyName = "My Company"; public int age; public string name; } class MyDerivedClass: MyBaseClass { static void Main() { //Create an instance of MyDerivedClass //and assign values to its fields. MyDerivedClass m1 = new MyDerivedClass(); m1.age = 42; m1.name = "Sam"; //Do a shallow copy of m1 //and assign it to m2. MyDerivedClass m2 = (MyDerivedClass) m1.MemberwiseClone(); } }`

  A graphical representation of m1 and m2 might look like this

  `+---------------+ | 42 | m1 +---------------+ | +---------|-----------------> "Sam" +---------------+ /|\ | +---------------+ | | 42 | | m2 +---------------+ | | +--------|---------------------| +---------------+`

  The method creates a shallow copy by creating a new object, and then copying the nonstatic fields of the current object to the new object. If a field is a value type, a bit-by-bit copy of the field is performed. If a field is a reference type, the reference is copied but the referred object is not; therefore, the original object and its clone refer to the same object.

  For example, consider an object called X that references objects A and B. Object B, in turn, references object C. A shallow copy of X creates new object X2 that also references objects A and B. In contrast, a deep copy of X creates a new object X2 that references the new objects A2 and B2, which are copies of A and B. B2, in turn, references the new object C2, which is a copy of C. The example illustrates the difference between a shallow and a deep copy operation.

  There are numerous ways to implement a deep copy operation if the shallow copy operation performed by the method does not meet your needs. These include the following:

  Call a class constructor of the object to be copied to create a second object with property values taken from the first object. This assumes that the values of an object are entirely defined by its class constructor.

  Call the method to create a shallow copy of an object, and then assign new objects whose values are the same as the original object to any properties or fields whose values are reference types. The DeepCopy method in the example illustrates this approach.

  Serialize the object to be deep copied, and then restore the serialized data to a different object variable.

  Use reflection with recursion to perform the deep copy operation.

  Creates a shallow copy of the current .

  A shallow copy of the current .

  0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Runtime.ConstrainedExecution.ReliabilityContract(System.Runtime.ConstrainedExecution.Consistency.WillNotCorruptState, System.Runtime.ConstrainedExecution.Cer.Success)
  System.Boolean `` `` `using System; class MyClass { static void Main() { object o = null; object p = null; object q = new Object(); Console.WriteLine(Object.ReferenceEquals(o, p)); p = q; Console.WriteLine(Object.ReferenceEquals(p, q)); Console.WriteLine(Object.ReferenceEquals(o, p)); } }`

  The output is

  True

  True

  False

  Unlike the method and the equality operator, the method cannot be overridden. Because of this, if you want to test two object references for equality and you are unsure about the implementation of the Equals method, you can call the method.

  However, the return value of the method may appear to be anomalous in these two scenarios:

  When comparing value types. If and are value types, they are boxed before they are passed to the method. This means that if both and represent the same instance of a value type, the method nevertheless returns false, as the following example shows.

  code reference: System.Object.ReferenceEquals#1

  When comparing strings. If and are strings, the method returns true if the string is interned. It does not perform a test for value equality. In the following example, and are equal because they are two instances of a single interned string. However, and are not equal, because although they are have identical string values, that string is not interned.

  code reference: System.Object.ReferenceEquals#2

  Determines whether the specified instances are the same instance.

  true if is the same instance as or if both are null; otherwise, false.

  The first object to compare. The second object to compare. 0
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.String

  The following example outputs the textual description of the value of an object of type to the console.

  `using System; class MyClass { static void Main() { object o = new object(); Console.WriteLine (o.ToString()); } }`

  The output is

  System.Object

  is the major formatting method in the .NET Framework. It converts an object to its string representation so that it is suitable for display. (For information about formatting support in the .NET Framework, see Formatting Types.)

  The default implementation of the method returns the fully qualified name of the type of the , as the following example shows.

  code reference: System.Object.ToString#1

  Because is the base class of all reference types in the .NET Framework, this behavior is inherited by reference types that do not override the method. The following example illustrates this. It defines a class named Object1 that accepts the default implementation of all members. Its method returns the object's fully qualified type name.

  code reference: System.Object.ToString#2

  Types commonly override the method to return a string that represents the object instance. For example, the base types such as , , and provide implementations that return the string form of the value that the object represents. The following example defines a class, Object2, that overrides the method to return the type name along with its value.

  code reference: System.Object.ToString#3

  ## Notes for the wrt

  When you call the method on a class in the wrt, it provides the default behavior for classes that don’t override . This is part of the support that the .NET Framework provides for the wrt (see .NET Framework Support for Windows Store Apps and Windows Runtime). Classes in the wrt don’t inherit , and don’t always implement a . However, they always appear to have , , and methods when you use them in your C# or Visual Basic code, and the .NET Framework provides a default behavior for these methods.

  Starting with the net_v451, the common language runtime will use IStringable.ToString on a wrt object before falling back to the default implementation of .

  wrt classes that are written in C# or Visual Basic can override the method.

  ## The wrt and the IStringable Interface

  Starting with win81, the wrt includes an IStringable interface whose single method, IStringable.ToString, provides basic formatting support comparable to that provided by . To prevent ambiguity, you should not implement IStringable on managed types.

  When managed objects are called by native code or by code written in languages such as JavaScript or C++/CX, they appear to implement IStringable. The common language runtime will automatically route calls from IStringable.ToString to in the event IStringable is not implemented on the managed object.

  Because the common language runtime auto-implements IStringable for all managed types in win8_appstore_long apps, we recommend that you do not provide your own IStringable implementation. Implementing IStringable may result in unintended behavior when calling ToString from the wrt, C++/CX, or JavaScript.

  If you do choose to implement IStringable in a public managed type that is exported in a wrt component, the following restrictions apply:

  You can define the IStringable interface only in a "class implements" relationship, such as

  `public class NewClass : IStringable`

  in C#, or

  `Public Class NewClass : Implements IStringable`

  in Visual Basic.

  You cannot implement IStringable on an interface.

  You cannot declare a parameter to be of type IStringable.

  IStringable cannot be the return type of a method, property, or field.

  You cannot hide your IStringable implementation from base classes by using a method definition such as the following:

  `public class NewClass : IStringable { public new string ToString() { return "New ToString in NewClass"; } }`

  Instead, the IStringable.ToString implementation must always override the base class implementation. You can hide a ToString implementation only by invoking it on a strongly typed class instance.

  Note that under a variety of conditions, calls from native code to a managed type that implements IStringable or hides its ToString implementation can produce unexpected behavior.

  Returns a string that represents the current object.

  A string that represents the current object.

  0
0