3

I am new to C# programming. Please help me.

I created a class Tester:

class Tester 
{
    public int a = 5;
    public int b = a;
}

Question 1 : Why am I not able to use this variable a for initializing the variable b.

Question 2: If I changed the variables to static then it works fine. Why is there a difference?

class Tester
{
    public static int a = 5;
    public static int b = a;
}

Question 3 : In previous example if I swap the sequence of variable then it works fine why because a is declaring after b . How can it initialize a?

class Tester
{
    public static int b = a; // 0
    public static int a = 5; // 5
}
Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Saurabh Mahajan
  • 2,937
  • 7
  • 25
  • 32
  • read this http://msdn.microsoft.com/en-us/library/aa691162(v=vs.71).aspx and this http://msdn.microsoft.com/en-us/library/aa691161(v=vs.71).aspx it's about variables and instance variables – Kamil Budziewski Oct 14 '13 at 09:31
  • I have found this to be a very helpful answer: http://stackoverflow.com/questions/1405709/what-is-the-static-variable-initialization-order-in-c – Jeroen Vannevel Oct 14 '13 at 10:33

3 Answers3

3

There are some icky initialization order issues when you use fields initializers. A simple example would be:

class Test {
   int a = b;
   int b;
   public Test() {
      b = 1;
   }
}

What will be the value of a? If you use the constructor-initializes-object rule then a will be 1. That however not the way it works under the hood, a would be 0 if the syntax where valid. A side-effect of the way field initializers are implemented, their code is injected into the constructor before the code in the body of the constructor. This problem gets a lot more convoluted when the class inherits base classes that have constructors.

This is too ugly, the C# language designers solved this by simply forbidding this kind of code. The rule is that you cannot reference this in a field initializer, that will create a reference to an object whose class constructor hasn't finished executing.

The rule is relaxed for static fields, there is no this reference and the CLR provides decent guarantees for class initializer execution order. That however doesn't avoid ambiguity, it is an exercise to guess what the field values will be in this example:

class Test {
    static int a = b + 1;
    static int b = a + 1;
}

Try it and see if you can make sense of the result. It is otherwise well-defined.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

Answer1: You cannot use an instance variable to initialize another instance variable. Why? Because the compiler can rearrange these - there is no guarantee that variable "a" will be initialized before "b", so the above line might throw a NullReferenceException.

Answer2: It works fine with static because static are initialize before other variables and their references are not changed.

Please let me know if it helps.

Anirudh Agarwal
  • 655
  • 2
  • 7
  • 29
  • yes your information is vary useful for me. thanks a lot Anirudh – Saurabh Mahajan Oct 15 '13 at 05:55
  • So it means static variable's sequence of initialization is same as they declared in code, compiler can't make any sequence change in case of static fields. But i don't think this is correct behavior of compiler with static variables. – Pavan Tiwari Oct 15 '13 at 06:01
1

As Anirudh said. You cannot use an instance variable to initialize another instance variable. Why? Because the compiler can rearrange these - there is no guarantee that a will be initialized before b.

You can use constructor for this.

class Tester
{
   public int a=5;
   public int b;
   public Tester()//constructor
   {
      b=a;
   }
}

or

class Tester
{
    public static int a = 5;
    public static int b;
    public Tester()//constructor
    {
        b = a;
    }
}
Manoj Naik
  • 386
  • 4
  • 18
  • Your first paragraph is not correct, the C# language does in fact provide a guarantee. Section 10.11.2 in the language spec, "The variable initializers are executed in the textual order in which they appear in the class declaration." – Hans Passant Oct 14 '13 at 10:40