Comparing objects by value - 5: Structure Equality Problematic

In the previous publication, we derived the most complete and correct way to implement comparison by value of objects — instances of classes (which are Reference Types ) for .NET .

How do you need to modify the proposed method for the correct implementation of the comparison by the value of objects - instances of structures (which are "types by value" - Value Types )?

Instances of structures , by their very nature, are always compared by value.

For predefined types, such as Boolean or Int32 , comparing by value means comparing directly the values ​​of the structure instances.

If the structure is defined by the developer - user of the platform (User defined struct), then the default comparison is automatically implemented as a comparison of the field values ​​of the structure instances. (For details, see the description of the ValueType.Equals (Object) method and == and ! = Operators). It also automatically implements the ValueType.GetHashCode () method, which overlaps the Object.GetHashCode () method in a specific way .

And in this case there are several significant pitfalls:

1. When comparing field values, reflection is used, which affects performance.

   
   

2. A structure field may not have a “significant” , but a reference type, and in this case, a comparison of fields by reference may not be appropriate from the subject (domain) point of view, and it may be necessary to compare fields by value (although in the general case, using reference fields in the structure can considered an incorrect architectural solution).
   (The documentation recommends creating for your structure your own implementation of comparison by value to increase performance and most accurately reflect the value of equality for this type.)

   
   

3. It may turn out that, from the substantive point of view, not all fields should participate in the comparison (although, again, for structures in general, this can be considered an incorrect decision).

   
   
4. And finally, the default implementation of the ValueType.GetHashCode () method does not meet the general requirements for implementing the GetHashCode () method (which we talked about in the first publication ):

• the value of the hash code obtained using ValueType.GetHashCode () may be unsuitable for use as a key in the hash table;
• if the value of one or several fields of the object has changed, then the value obtained using ValueType.GetHashCode () may also be unsuitable for using the key in the hash table;
• the documentation recommends creating your own implementation of the GetHashCode () method, which most accurately reflects the concept of the hash code for this type.

Thus, on the one hand, there are several reasons of a general nature pushing the structures to implement their own mechanism for comparing objects by value (performance, matching the domain model).

On the other hand, the need for a correct implementation of the GetHashCode () method automatically leads to the need to implement a comparison by value, since due to the nature of the hash code (see the first publication ), the GetHashCode () method must "know" what data (fields) and how they participate in the comparison by value.

On the third hand, a special case is possible when there is a “simple” structure consisting, for example, only of structure fields, for which a byte-by-by-by-means comparison with reflection deliberately gives a semantically correct result (for example, Int32 ).

In this case, it is possible to implement GetHashCode () correctly (so that for equal objects the hash code is always the same) without creating your own implementation of the comparison by value.

For example:

public struct Point { private int x; private int y; public int X { get { return x; } set { x = value; } } public int Y { get { return y; } set { y = value; } } public override int GetHashCode() => x.GetHashCode() ^ y.GetHashCode(); } 

However, in the case of rewriting this simple example using "automatically implemented properties", the picture looks less clear:

  public struct Point { public int X { get; set; } public int Y { get; set; } public override int GetHashCode() => X.GetHashCode() ^ Y.GetHashCode(); } 

The “autospecs” documentation talks about the automatic creation of an anonymous backing field corresponding to public properties.

Strictly speaking, it is not clear from the description whether, from the point of view of the default implementation of the comparison, two Point objects with the same X and Y values ​​will be equal:

• If the default implementation compares the values ​​of the fields with the help of reflection, then how do different objects compare anonymous fields - that these fields correspond to each other, since each corresponds to property X, and these correspond to each other, since each matches Y?

What if backing-fields are created in two different objects with different names like (x1, y1) and (x2, y2)?
Will it be taken into account when comparing that x1 corresponds to x2, and y1 corresponds to y2?

• Are there any other auxiliary fields created that may have different values ​​for the same (X, Y) objects from the interface point of view? If so, will these fields be taken into account when comparing?
• Or, perhaps in the case of a structure with auto-properties , will the byte-by-by-by-by-by -s comparison of the entire contents of the structure be used, without comparing individual fields? If so, will the backing fields for each object be created in memory always in the same order and with the same offsets?

Most likely, somewhere in the depths of the documentation or books of authors related to the development of the platform, you can find positive answers to these questions - in the sense that the behavior for structures with explicitly declared fields and structures with automotive properties will give the same result with default comparison by value

Or, if some part is undocumented, then, most likely, the behavior of the compiler and the runtime environment will be expected.

Taking into account the general set of arguments, it seems that in the general case it is preferable for structures to implement their own comparison by value.

A detailed example with detailed comments, based on the Person entity familiar from previous publications, will be considered in the next publication .