简体   繁体   中英

Declaring an object of a class as null

When we only declare an object of a class without instantiating it like below, does it treats as null or empty or else?

Example1: Directory objDEntry;

Example2: Directory objDEntry = null;

Is there a difference between Example1 and Example2 or they are same?

It depends ; if you declare a field , eg

  public class MyClass {
    // objDEntr will be initialized by null
    Directory objDEntr;
    // the initialization is redundant here
    Directory objDEntry2 = null;  
    ... 

there's no difference, since fields are initialized by their default values and null is the default value for reference types. However, local variables are not initialized by default; so

  public static void MyMethod() {
    // objDEntry contains trash, must be initialized further
    Directory objDEntry; 
    // objDEntry2 is null
    Directory objDEntry2 = null;  
    ...

in the "Example 1" objDEntry contains trash, while in the "Example 2" objDEntry is properly initialized and contains null .

When you declare a reference type variable, the variable is basically a pointer to a collection of memory that represents a particular object. For example, in your case, when you declare a Dictionary variable:

Dictionary objDict;

That creates the pointer that will point at a Dictionary object in memory. When it's first declared like this, however, the variable isn't actually pointing at anything. Attempting to use the variable in any calculations at this point will result in a NullReferenceException .

On the flip side, when you create an object, it allocates memory for that object. (For the sake of this explanation, precisely where it allocates the memory is irrelevant.) So when you create a Dictionary object:

new Dictionary();

That will allocate the memory necessary to represent the Dictionary object.

When you tie these two actions together, that is what you are doing when you assign a reference-type variable:

Dictionary objDict = new Dictionary();

The variable objDict is now pointing at the memory allocated for the object.

Now when you assign null to the reference variable, you are basically resetting it to its default state - the state in which the pointer is pointing at nothing. In that sense, the lines:

Dictionary objDict;

and

Dictionary objDict = null;

will be identical as far as the CLR is concerned. However, the C# compiler comes with its own set of restrictions where variable declarations are concerned. It will mandate through compilation errors that a reference variable cannot be used until it is guaranteed to have been explicitly instantiated. For example, the following will compile, but will throw an error at runtime:

Dictionary objDict = null;
string s = objDict.ToString();

This code, however, will fail at compilation, with the error message of "Use of unassigned local variable 'objDict'" :

Dictionary objDict;
string s = objDict.ToString();

As Dmitry says in his answer, however, this rule only applies to local variables. Class-level and above variables will not produce such an error, so the following code will be fine:

Dictionary objDict;

public void DictToString()
{
    string s = objDict.ToString();
}

To explain what Hameed is talking about, a reference variable is a pointer at an object in memory, but when you take an assigned variable and set it to null , that previous object is still in memory - it has just been orphaned. When the CLR executes garbage collection, it checks for precisely these orphaned objects and releases their memory.

It will not (usually) collect objects that still have active pointers pointing at them, however, which is why for some objects it can be good practice to dispose of them by setting the variables that point to them to null so that they will be properly released the next time garbage collection comes around.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM