The csc.exe compiler - member variables
-
Does the compiler initialise the member variables when the compiler-created constructor is called? For example
class MyClass { public int mTinyInt { get { return mTinyInt; } set { mTinyInt = value; } } } // in code // Create an instance, calling the compiler-created constructor. MyClass MyObj = new MyClass(); // Output varibles to the screen to see what the compiler has done. Console.WriteLine("\n\nThe int values is:\n {0}", mTinyInt);This however gives me a stack overflow. I would assume that the compiler would make all members 0 in the created constructor, but is this not so? Obseve everything, remember more... -
Does the compiler initialise the member variables when the compiler-created constructor is called? For example
class MyClass { public int mTinyInt { get { return mTinyInt; } set { mTinyInt = value; } } } // in code // Create an instance, calling the compiler-created constructor. MyClass MyObj = new MyClass(); // Output varibles to the screen to see what the compiler has done. Console.WriteLine("\n\nThe int values is:\n {0}", mTinyInt);This however gives me a stack overflow. I would assume that the compiler would make all members 0 in the created constructor, but is this not so? Obseve everything, remember more...private int mTinyInt = 1; public int mPubRepTinyInt { get { return mTinyInt; } set { mTinyInt = value; } }So when I want to use mTinyInt I actually call mPubRepTinyInt. This cannot be right surely - where am I going wrong? Obseve everything, remember more... -
Does the compiler initialise the member variables when the compiler-created constructor is called? For example
class MyClass { public int mTinyInt { get { return mTinyInt; } set { mTinyInt = value; } } } // in code // Create an instance, calling the compiler-created constructor. MyClass MyObj = new MyClass(); // Output varibles to the screen to see what the compiler has done. Console.WriteLine("\n\nThe int values is:\n {0}", mTinyInt);This however gives me a stack overflow. I would assume that the compiler would make all members 0 in the created constructor, but is this not so? Obseve everything, remember more...Ok I've got it now, they are properties and I access the actual members using them. I saw an example about a Person class, a Name property, and a myName member variable on the MSDN site. I'm not sure why all this is necessary (the best reason I've seen on MSDN is b/c it gives a nice 'clean' look to the code. wtf? Better than Person.mPersonName = "John" - is it not down to how you name your variables?). Thanks to everyone who had a look at this. Obseve everything, remember more...
-
Ok I've got it now, they are properties and I access the actual members using them. I saw an example about a Person class, a Name property, and a myName member variable on the MSDN site. I'm not sure why all this is necessary (the best reason I've seen on MSDN is b/c it gives a nice 'clean' look to the code. wtf? Better than Person.mPersonName = "John" - is it not down to how you name your variables?). Thanks to everyone who had a look at this. Obseve everything, remember more...
Because properties allow you to perform validation and other useful functions, where fields cannot. Lets say your
Personclass has anAgeproperty (in actuality, it's better to store their birthday, but this is only an example...). You could use aUInt16or something, but unsigned integers are not CLS-compliant. So, you want to make sure that only a positive integer is passed to theAgeproperty:public class Person
{
private int age;
public int Age
{
get { return this.age; }
set
{
if (value <= 0) throw new ArgumentException();
this.age = value;
}
}This is used a lot throughout the .NET Framework and in many other applications, even in non-.NET applications (like in VB, Java Beans, JScript, etc.). If also allows you to control member access. If you use fields, you can't control whether other classes can write to it (you could use the
readonlykeyword, but then your field can only be initialized in the static or an instance constructor, which isn't always desired. To do this, you merely use thegetaccessor and don't use thesetaccessor (so other code can't change it via that property). There is many, many reasons to use properties over fields.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
Because properties allow you to perform validation and other useful functions, where fields cannot. Lets say your
Personclass has anAgeproperty (in actuality, it's better to store their birthday, but this is only an example...). You could use aUInt16or something, but unsigned integers are not CLS-compliant. So, you want to make sure that only a positive integer is passed to theAgeproperty:public class Person
{
private int age;
public int Age
{
get { return this.age; }
set
{
if (value <= 0) throw new ArgumentException();
this.age = value;
}
}This is used a lot throughout the .NET Framework and in many other applications, even in non-.NET applications (like in VB, Java Beans, JScript, etc.). If also allows you to control member access. If you use fields, you can't control whether other classes can write to it (you could use the
readonlykeyword, but then your field can only be initialized in the static or an instance constructor, which isn't always desired. To do this, you merely use thegetaccessor and don't use thesetaccessor (so other code can't change it via that property). There is many, many reasons to use properties over fields.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
Hey that makes sense. Thanks, I'll refer to what you said while I'm learning C#. Obseve everything, remember more...