Structs and identity

Question

As it says on MSDN documentation and elsewhere, a struct has no identity and should therefore represent an "eternal" value that never changes, eg a phone number (the phone number doesn't change, but you get a new one).

How can this influence my coding decisions?

Based on that knowledge, am I right in thinking that no identity means that if two structs have the same data, there is no way to tell them apart, so conceptually, they are the same thing. So two structs used in a codebase for a number for example (7) are always the same thing. So with classes, two objects with the same data (e.g. a person object with just name) can be different people, yet with structs, this distinction does not exist. So a struct that may represent a skill (e.g. fishing) will always be the same (there is no identity to distinguish it).

Hope that makes sense.

Thanks

Answer 1

Structs share most of the same syntax as classes, but according to MSDN:

The struct type is suitable for representing lightweight objects

The key difference between them is that Classes generate reference-type objects while Structs generete value-type objects, which means that the following operation:

Point A = new Point();
Point B = A;

Will make A and B access the same in-memory object if Point is a Class, or create a new copy of A and assign it to B if Point is a Struct.

In the case Point is a Struct, the following relations hold:

Object.Equals(A,B) == true
Object.ReferenceEquals(A,B) == false

Hence you can tell them apart, and the two structs are not the same thing because each one of them is an object in memory.

This SO question discusses when it is a good idea to use Structs.

Answer 2

A struct is a value. A class is an object. It is very similar to real life, where 42 will always equal 42, but you can have two people by the name of John Smith.

What you said in the question is a very good outline of the concepts of value types vs. reference types.

As for how it should influence your coding, always code so that a value will equal an identical value, e.g. 42 must always equal 42. There are some cases where a reference type should be compared by value instead of identity (e.g. string). But in the majority of cases, reference types compare by identity.

If you can measure or calculate it, it belongs in a value type. Otherwise, use a reference type.

Answer 3

The "struct" or "record" concept was created before the "class" concept. And sometimes, can be interchanged.

When to use a variable, field or instance of an struct:

(1) When Only Data members are need it, without methods. Or has few methods, that are barely used, such as constructors.

Example:

struct CoordinateStruct
{
  int X;
  int Y;
}

(2) When a great quantity of elements, are required, and since objects, use additional memory, sometimes not visible, migrating methods to a container element, such another object, a module (namespace) like object, or singleton object (Flyweight design pattern).

Before:

class PointClass
{
  int X;
  int Y;
  // its also an object / class
  Color Color;

  public void assign(int NewX, int NewY, Color NewColor) { ... }
  public void move(int addX, int addNewY) { ... }
}

// multiple element container
class CADAppClass
{
  List<Point> Points;

 // ...
}

// Not enough memory Exception !!!

After:

struct PointStruct
{
  int X;
  int Y;
  // its a low memory integer
  int Color;      
}

// multiple element container
class CADAppClass
{
  List<Point> Points;

  public void assignPoint
    (ref PointStruct Point, int NewX, int NewY, Color NewColor) { ... }
  public void movePoint
    (ref PointStruct Point, int addX, int addNewY) { ... }

 // ...
}

(3) When you need to encapsulate the data elements, even if its a small quantity of elements, in a variable, even if there are methods, operators, events or "messages". The encapsulation, maybe for serializacion as an example (loading from D.L.L., DCOM, JSON, plain data files).

Before:

class CustomerClass
{
  String FirstName;
  String LastName;

  public void Store(Stream Destination) { ... }
  public void Load(Stream Source) { ... }

  public void CopyTo(CustomerClass Destination) { ... }
  public void CopyFrom(CustomerClass Source) { ... }
}

After:

struct CustomerStruct
{
  char[100] FirstName;
  char[100] LastName;
}

// one to one, nested, relationship, seems redudant,
// but required
Class CustomerClass
{
  CustomerStruct Data;

  public void Store(Stream Destination) { ... }
  public void Load(Stream Source) { ... }

  public void CopyTo(CustomerStruct Destination) { ... }
  public void CopyFrom(CustomerStruct Source) { ... }
}

I used this one, with enumerations, instead of structs, in programming languages that are Object & Class Oriented, but, that doesn't treat enumerations as objects (Example: Object Oriented PHP & Object Pascal), as Java or C#, does.

(4) A mix of the previous cases, or a scenario, not considerated.

Cheers.