Initialization of instance fields vs. local variables

Question

I have always been wondering about why in the following example it is OK to not initialize the instance field (relying that it will have its default value) and accessing it, while local variables apparently must be initialized, even if I initialize it to default value it would get anyway...

  public class TestClass
  {
    private bool a;

    public void Do()
    {
      bool b; // That would solve the problem: = false;
      Console.WriteLine(a);
      Console.WriteLine(b); //Use of unassigned local variable 'b'
    }
  }

Answer 1

For local variables, the compiler has a good idea of the flow - it can see a "read" of the variable and a "write" of the variable, and prove (in most cases) that the first write will happen before the first read.

This isn't the case with instance variables. Consider a simple property - how do you know if someone will set it before they get it? That makes it basically infeasible to enforce sensible rules - so either you'd have to ensure that all fields were set in the constructor, or allow them to have default values. The C# team chose the latter strategy.

Answer 2

It is governed by Definite Assignment rules in C#. Variable must be definitely assigned before it is accessed.

5.3 Definite assignment

At a given location in the executable code of a function member, a variable is said to be definitely assigned if the compiler can prove, by a particular static flow analysis (§5.3.3), that the variable has been automatically initialized or has been the target of at least one assignment.

5.3.1 Initially assigned variables

The following categories of variables are classified as initially assigned:

• Static variables.

• Instance variables of class instances.

• Instance variables of initially assigned struct variables.

• Array elements.

• Value parameters.

• Reference parameters.

• Variables declared in a catch clause or a foreach statement.

5.3.2 Initially unassigned variables

The following categories of variables are classified as initially unassigned:

• Instance variables of initially unassigned struct variables.

• Output parameters, including the this variable of struct instance constructors.

• Local variables, except those declared in a catch clause or a foreach statement.

Answer 3

When a chunk of memory is allocated for a new object instance, the runtime writes zeros across the entire block, ensuring that the new object starts at a known state - this is why integers default to 0, doubles default to 0.0, pointers & object references to null, and so on.

It would be possible, in theory, to do the same to stack frames allocated as as part of method calls. The overhead, though would be high - it would drastically slow down calls to other methods, and therefore isn't attempted.

Answer 4

Instance variables have a default value. From the C# 3.0 specification:

5.1.2.1 Instance variables in classes

An instance variable of a class comes into existence when a new instance of that class is created, and ceases to exist when there are no references to that instance and the instance’s finalizer (if any) has executed.

The initial value of an instance variable of a class is the default value (§5.2) of the variable’s type.

For the purpose of definite assignment checking, an instance variable is considered initially assigned.

Answer 5

It's a compiler limitation. The compiler tries to prevent you using an unassigned variable wherever it can, which is a good thing as using uninitialised variables used to be a common source of bugs in old C code.

The compiler can't however know whether the instance variable is initialised before you hit that method call because it could be set by any other method, which may be called in any order by external code.

Answer 6

The implicit constructor initializes the instance variable for you. Even when you specify a c'tor but don't initialize a field, it's done for you as part of creating the object on the heap. That's not true of stack local variables.

Answer 7

It's really just a matter of what the warning is able to tell you. There's really no way for the warning to be sure that some other method hasn't initialized the class variable, so it only warns on the one it can be certain isn't initialized.

Also, it's a warning and not an error because there's nothing technically wrong with using the unassigned variable (it's guaranteed to be 'false') but it's probably a logic error to have it unassigned.