A field initializer is part of the field declaration, and consists of an equals sign followed by an expression that evaluates to a value. The initialization value must be determinable at compile time.

Besides being convenient, auto-implemented properties allow you to easily insert a property where you might be tempted to declare a public field.
You might, however, be tempted to release a version of the code with a public field, and then in a later release change the field to a property. However, the semantics of a compiled variable and a compiled property are different. If, in a later release, you were to switch from a field to a property, any assemblies accessing that field in the first release would have to be recompiled to use the property. If you use a property in the first place, the client doesn’t have to be recompiled.

B b = new B();

Originally Posted by LizR

Help with Code Tags

C# Syntax (Toggle Plain Text)

B b = new B();

B b = new B();

Does have a value - as in effect it is a pointer to a B shaped peice of memory. Ergo, it has value, it is B shaped.

Originally Posted by LizR

2) In your code if you have

Help with Code Tags

C# Syntax (Toggle Plain Text)

Class X
{
 public int A;
}

Class X { public int A; }

And you change it to

Help with Code Tags

C# Syntax (Toggle Plain Text)

class X
{
private int a;
public int A
{
 get { return a; }
 set { a=value; }
}

class X { private int a; public int A { get { return a; } set { a=value; } }

You've changed where in memory its pointing to.. so it would need recompliation.

Originally Posted by LizR

3) because, constants are hard coded into the exe, eg if you put in A= 50; rather than it taking A and placing 50 in it it, all instances of A are pointing to a reference of 50 within the exe (ish) - give or take a bit.

BTW – is class ( not an instance of class ) created at compile time, or at runtime?

Originally Posted by ddanbe

A class is a discription of an object which is created(instantiated) at runtime.

Originally Posted by srubys

1)


So b field has a value even though it doesn’t actually point to a specific location ( at compile time )? But couldn't then same argument also applied to, say, integer field:

Help with Code Tags

C# Syntax (Toggle Plain Text)

public int someValue = new A().someMethod();

public int someValue = new A().someMethod();

Here someValue will be initialized at run time, when instance method someMethod() is called.
But we could still argue that at compile time someValue is a holder of a integer shaped piece of memory and thus someValue has a value, it is int shaped?!

2)


I realize that in the example you provided client code also needs to change ( since basically the interface changed ). But I don’t understand why client code should also change if it wants to access member A of the following class:

Help with Code Tags

C# Syntax (Toggle Plain Text)

class X
{
  public int A
}

class X { public int A }

and we change class X to

Help with Code Tags

C# Syntax (Toggle Plain Text)

 
class X
{
    public int A
   {
         get; set;
    }
}

class X { public int A { get; set; } }

Here client code should remain the same, since the interface didn't change!

3)
If I understood you correctly, then compiler doesn't place a constant A into an assembly, but rather just its value?
I don't quite understand what is gained by implementing constants in such way?

Also, why isn't static readonly field treated in the same manner?

BTW – is class ( not an instance of class ) created at compile time, or at runtime?
thank you