Can someone explain what the point of nulling an object before it goes out of scope is?

I have seen code with the following logic in a few places:

public void func()
{
   _myDictonary["foo"] = null;
   _myDicti开发者_开发百科onary.Remove("foo");
}

What is the point of setting foo to null in the dictionary before removing it?

I thought the garbage collection cares about the number of things pointing to whatever *foo originally was. If that's the case, wouldn't setting myDictonary["foo"] to null simply decrease the count by one? Wouldn't the same thing happen once myDictonary.Remove("foo") is called?

What is the point of _myDictonary["foo"] = null;

edit: To clarify - when I said "remove the count by one" I meant the following:

- myDictonary["foo"] originally points to an object. That means the object has one or more things referencing it.

- Once myDictonary["foo"] is set to null it is no longer referencing said object. This means that object has one less thing referencing it.

There is no point at all.

If you look at what the Remove method does (using .NET Reflector), you will find this:

this.entries[i].value = default(TValue);

That line sets the value of the dictionary item to null, as the default value for a reference type is null. So, as the Remove method sets the reference to null, there is no point to do it before calling the method.

Setting a dictionary entry to null does not decrease the ref count, as null is a perfectly suitable value to point to in a dictionary.

The two statements do very different things. Setting the value to null indicates that that is what the value should be for that key, whereas removing that key from the dictionary indicates that it should no longer be there.

There isn't much point to it.

However, if the Remove method causes heap allocations, and if the stored value is large, a garbage collection can happen when you call Remove, and it can also collect the value in the process (potentially freeing up memory). Practically, though, people don't usually worry about small things like this, unless it's been shown to be useful.

Edit:

Forgot to mention: Ideally, the dictionary itself should worry about its own implementation like this, not the caller.

It doesn't make much sense there, but there are times when it does make sense.

One example is in a Dispose() method. Consider this type:

public class Owner
{
    // snip

    private BigAllocation _bigAllocation;

    // snip

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // free managed resources
            if (_bigAllocation != null)
            {
                _bigAllocation.Dispose();
                _bigAllocation = null;
            }
        }
    }
}

Now, you could argue that this is unnecessary, and you'd be mostly right. Usually Dispose() is only called before Owner is dereferenced, and when Owner is collected, _bigAllocation will be, as well... eventually.

However:

Setting _bigAllocation to null makes it eligible for collection right away, if nobody else has a reference to it. This can be advantageous if Owner is in a higher-numbered GC generation, or has a finalizer. Otherwise, Owner must be released before _bigAllocation is eligible for collection.

This is sort of a corner case, though. Most types shouldn't have finalizers, and in most cases _bigAllocation and Owner would be in the same generation.

I guess I could maybe see this being useful in a multi-threaded application where you null the object so no other thread can operate on it. Though, this seems heavy handed and poor design.

If that's the case, wouldn't setting myDictonary["foo"] to null simply decrease the count by one?

Nope, the count doesn't change, the reference is still in the dictionary, it points to null.

I see no reason for the code being the way it is.

I don't know about the internals of Dictionary in particular, but some types of collection may hold references to objects which are effectively 'dead'. For example, a collection may hold an array and a count of how many valid items are in the array; zeroing the count would make any items in the collection inaccessible, but would not destroy any references to them. It may be that deleting an item from a Dictionary ends up making the area that holds the object available for reuse without actually deleting it. If another item with the same hash code gets added to the dictionary, then the first item would actually get deleted, but that might not happen for awhile, if ever.

This looks like an old C++ habit.

I suspect that the author is worried about older collections and/or other languages. If memory serves, some collections in C++ would hold pointers to the collected objects and when 'removed' would only remove the pointer but would not automatically call the destructor of the newly removed object. This causes a very subtle memory leak. The habit became to set the object to null before removing it to make sure the destructor was called.