I'm working on a TCP socket related application, where an object I've created refers to a System.Net.Sockets.Socket object. That latter object seems to become null and in order to understand why, I would like to check if my own object gets re-created. For that, I thought of the simplest possible approach by checking the memory address of this. However, when adding this to the watch-window I get following error message:

Name    Value
&this   error CS0211: Cannot take the address of the given expression

As it seems to be impossible to check the memory address of an object in C#, how can I verify that I'm dealing with the same or another object when debugging my code?

CodePudding user response：

In C#, objects are moved during garbage collection. You can't simply take the address of it, because the address changed when the GC heap is compacted.

Dealing with pointers in C# requires unsafe code and you leave the terrain of safe code, basically making it as unsafe as C .

You can use a debugger like windbg, which displays the memory addresses of objects - but they will still change when GC moves them around.

If you want to see if a new instance of your class gets created, why not set a breakpoint in the constructor?

CodePudding user response：

I am convinced with @thomas answer above.

you can add a unique identifier (such as a GUID) property to your object and use that to determine if you have the same object.

you could override the Equals method to compare two objects if they same as below.

public class MyClass
{
    public Guid Id { get; } = Guid.NewGuid();

    public override bool Equals(object obj)
    {
        return obj is MyClass second && this.Id == second.Id;
    }
}

CodePudding user response：

As already explained, addresses of objects are not a viable means of reasoning about objects in garbage-collected virtual machines like DotNet. In DotNet you may get the chance to observe the address of an object if you use the fixed keyword, unsafe blocks, or GCHandle.Alloc(), but these are all very hacky and they keep objects fixed in memory so they cannot be garbage collected, which is something that you absolutely do not want. The moment you unfix an object, then its address is free to change, so you cannot keep track of it.

Luckily, you do not need any of that, because all you want is a mnemonic for each object, for the purpose of identifying it during troubleshooting. For this, you have two options:

1. Create a singleton which issues unique ids, and in the constructor of each object invoke this singleton to obtain a unique id, store the id with the object, and include the id in the ToString() method of the object, or in whatever other method you might be using for debug display.

2. Just use the following ready-made method: System.Runtime.CompilerServices. RuntimeHelpers.GetHashCode( object ); This method returns what is known in other circles as The Identity Hash-Code of an Object. It is guaranteed to remain unchanged throughout the lifetime of the object, but it is not guaranteed to be unique among all objects. However, since it is 32-bits long, it will be a cold day in hell before another object gets issued the same hash code by coincidence, so it will serve all your troubleshooting purposes just fine.

Do yourself a favor and display the Identity Hash Code of your objects in hexadecimal; the number will be shorter, and will have a wider variety of digits than decimal, so it will be easier to retain in short-term memory while troubleshooting.