Must value be determined at compile-time?

[srubys]

hi

Just a few days ago I've started learning C#.

BTW - I hope I'm not breaking any forum rules by putting three questions inside a single thread, but I don't want to "spam" this forum by making too many threads.

1)
From the book:

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.

But if initialization value must indeed be determined at compile time, then the following code would produce an error, due to the fact that here the initialization value can’t be known at compile time, since memory on the heap is only allocated at run-time:

class A
{
     B b = new B(); // here value of  b can't be known until run time
}

2)
The following quote talks about about the usefulness of auto-implemented properties:

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.

Say I created class X, the member of which is also a public instance field named A, and put this class into assembly. Now some third party writes a code that access this field A. Later I decide to replace public field A with public property called A ( of same type as field was ), so I rewrite and recompile my class.
Now client would still access this property using the same code as it used for accessing field A -->

void Main
{
...
X x = new X(); 
int i = x.A;
...
}

And since the client code remains unchanged, I don't see the need for recompiling it?

3) Why must the value of constant be determined at compile time rather than at run time, while read only field can be determined at run time?

[LizR]

1)

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.

2) In your code if you have

Class X
{
 public int A;
}

And you change it to

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.

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.

[ddanbe]

B b = new B();

Under the hood new B() might even change so many variables that it is possible the world is totally changed after executing this statement.

[srubys]

hi

1)

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.

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:

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)

2) In your code if you have

Class X
{
 public int A;
}

And you change it to

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.

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:

class X
{
  public int A
}

and we change class X to

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

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

3)

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.

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

[ddanbe]

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

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

[srubys]

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

Sorry about that. I know class is just a blueprint, what I meant was if static members and static methods are created at compile time or at run time?

[LizR]

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:

Sort of, but, very basic elemental types are slightly different..

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?!

Ah but who are you to amke the assumption that .somemethod() only returns an int, it could do so much more. hence it needs the change.

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:

class X
{
  public int A
}

and we change class X to

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

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

Ah, but, it needs to generate the missing private variable etc.

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?

Readability, and the fact you set it in one place in your code eg "FPS = 30" and then you can type FPS everywhere rather than 30, and more easily maintainable..

What if then you had MAX_CONNECTIONS =30.. and you see "30" somewhere.. which is it?

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

Read only properties are still changable by the private variable.. just not outside the class.

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

The class template is done at compile time, the instance, runtime.