Field vs Static Field, basic question...

  • Thread starter Thread starter Learning C#
  • Start date Start date
L

Learning C#

I hope this is an ok place to post real beginner stuff.

Basically I need to know the difference between a field, and a static field.

My book sux and doesn't explain this well. It seems that a field is scoped
the same and can do the same things.
IE a field is declared in a class instead of a method so all methods of the
class can use it.
And a static field is described in my book as the same?

I must be missing something...
 
Learning C# said:
I hope this is an ok place to post real beginner stuff.

Basically I need to know the difference between a field, and a static field.

My book sux and doesn't explain this well. It seems that a field is scoped
the same and can do the same things.
IE a field is declared in a class instead of a method so all methods of the
class can use it.
And a static field is described in my book as the same?

I must be missing something...
Click to expand...

It's the same difference as between a static method and an instance
method, and a static property and an instance property.

Anything "static" is to do with the type in general, not any particular
instance of the type. (You might use a static field to count how many
instances have been created, for example.)

Anything non-static is specific to that particular instance. (You might
use an instance field to say, "This instance was the <n>th one to be
created, for example.)
 
Learning C# said:
I hope this is an ok place to post real beginner stuff.

Basically I need to know the difference between a field, and a static field.

My book sux and doesn't explain this well. It seems that a field is scoped
the same and can do the same things.
IE a field is declared in a class instead of a method so all methods of the
class can use it.
And a static field is described in my book as the same?

I must be missing something...
Click to expand...

A field (from what I understand is a property without a property declaration
(public variable)).
Apart from that everything that applies to properties applies to fields
(static vs instance etc...)

ie
public class x
{
private int m_x; //private var x
public int y; //field var y
private static int m_X; //private static var X
public static int Y; //static field Y

public int x //instance property
{
set
{
return m_x;
}
get
{
m_x = value;
}

public static int X //static property
{
get
{
return m_X;
}
set
{
m_X = value;
}
}
 
John Baro said:
A field (from what I understand is a property without a property declaration
(public variable)).
Click to expand...

No. A field is a variable. A property doesn't have to have a variable
backing it at all.
Apart from that everything that applies to properties applies to fields
(static vs instance etc...)
Click to expand...

Well, lots of things, but not everything. For instance, a property
can't be passed by reference.

A property is essentially a method (or pair of methods) and a bit of
metadata to allow those methods to be accessed using field-like syntax.

But yes, the meaning of "static" is the same for all member types.
 
Thanks for the reply.
Just so I am clear, so they both are used to track the number of instances?
 
That's the beauty of programing, you can do almost everything you want
:)

The idea behind Jon's explanation is other:


public class MyClass
{
public int inst = 1;
public static int sta = 1;

public int GetSum()
{
return inst + sta;
}
}

....

MyClass a = new MyClass();
MyClass b = new MyClass();

a.inst = 5;
b.inst = 6;
MyClass.sta = 7;

now:
a.GetSum will return 12, and b.GetSum will return 13.

So, the sta field is one and the same for all objects of that class,
while inst is different per instance.


Sunny


Thanks for the reply.
Just so I am clear, so they both are used to track the number of instances?
Click to expand...
 
Learning C# said:
Thanks for the reply.
Just so I am clear, so they both are used to track the number of
instances?
Click to expand...

Not at all - that was just an example which demonstrated something
general to the whole type (namely the number of instances generated in
total) and something specific to each instance (the "instance number").
 
Sunny said:
So, the sta field is one and the same for all objects of that class,
while inst is different per instance.
Click to expand...

Not quite - there *is* no "sta" field for "all objects of that class" -
there is just the "sta" field for the class itself, rather than for
*any* instance.
 
Yes, you are right.

Not quite - there *is* no "sta" field for "all objects of that class" -
there is just the "sta" field for the class itself, rather than for
*any* instance.
Click to expand...
 
Jon Skeet said:
No. A field is a variable.
A property doesn't have to have a variable backing it at all.
Click to expand...
Agreed (Forgot to mention :)
Well, lots of things, but not everything. For instance, a property
can't be passed by reference.
Click to expand...
Correct.
Can you pass a "field" by ref then?
ie
MyMethod(ref MyClassInstance.MyField)

MyMethod(ref MyClassInstance.MyProperty) //will not work

(Goes away and tests)
Yes, it appears you can.
Learn something new every day.
A property is essentially a method (or pair of methods) and a bit of
metadata to allow those methods to be accessed using field-like syntax.
Click to expand...

But "appears" from the outside to be the same as a field.
 
John Baro said:
But "appears" from the outside to be the same as a field.
Click to expand...

Well, it has (as I said) field-like syntax. That's the only similarity
with a field. You can still tell (from the outside) that it's a
property in any number of ways, including reflection.

It is my belief that everyone should know when they're changing a field
(which should be extremely rare outside the class itself) and when
they're changing a property, and that properties are more like methods
in all but syntax than they are like fields.
 
The answer to your question has been covered, but a caveat to a static field
is that you will want to be very careful in how you expose that field so
that you don't have threading problems with other instances of the class
accessing the variable.
 
Back
Top