|
To initialize static fields.
-Blake
|
|
|
|
|
say if i have 1 static var in my class and one non-static one...
so do i need 2 constructors? a static one and a non static one?
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
Yup.
Though C# does have a convenient feature of creating constructors for you based on variable initialization statements. This is particularly handy with static constructors. For example, the following two pieces of code are almost equivalent.
class Foo {
static int Bar = 42;
}
class Foo {
static int Bar;
static Foo() {
Bar = 42;
}
}
Aside from being less typing, it turns out that the first syntax is a little more efficient as well. The reason why is complicated and I won't try to cover it here, but if you are curious you can google for 'beforefieldinit'.
-Blake
|
|
|
|
|
one last question....
lets say i have a class
class Foo<br />
{<br />
static int iFoo<br />
int iBar<br />
}
in the class above how should my constructor look like??
should i have one constructor??
or two? one static constructor and one non static???
tks...
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
You can't do it with one constructor, but beyond that there's no one right answer, it depends how you are calculating the value you want to initialize those fields with. If the values are simple expressions, then don't write explicit constructors at all, just do:
class Foo {
static int foo = Date.Now.Year;
int bar = (int)(Random.Sample() * 100);
}Only write a static constructor if you need to execute logic that doesn't fit in an expression like that, say loading a static lookup table out of your config file or database.
Write instance constructors either, if you need more complicated code like above, or if you want to pass parameters that control the initialization.
On an unrelated note, don't use hungarian notation with C#. Have a look at Design Guidelines for Class Library Developers[^] on MSDN for that and other important style tips for C# and .NET.
-Blake
|
|
|
|
|
Blake is right, it all depends. The important thing to keep in mind is that one field is Type-based (the static field), and one field is instance-based. That static field value will be the same for all instances of the class. That instance field value will be different for each instance.
The ubiquitous example is the Company and Employees example. While the Company class may keep a count of Employee objects added or removed from it, another way to solve this is to have the Employee Type keep track of it:
public class Employee
{
private static int count = 0;
public Employee()
{
count++;
}
~Employee()
{
count--;
}
}While this is a very basic and impractical solution (because it doesn't allow for multiple companies to have different employees), it is just an example.
I use this a lot to initialize caches for objects in the same context, such as a download manager that keeps a cache of files. Different instances of that download manager (actually, it's a singleton now, but the following still applies...) share the same cache, just like different instances of Internet Explorer (actually, anything that uses URL monikers or the like) share the same cache on the filesystem (though it's not "initialized" per se). I do this in the static constructor to make sure that it is initialized before the class.
So, basically, the order for instantiating of two objects is done like so:- Static constructor (IL: .cctor)
- Instance constructor (IL: .ctor)
- Instance constructor (IL: .ctor)
- Destructor (IL: Finalize)
- Destructor (IL: Finalize)
Note, there is no "static destructor". Even if all instances of the Type have been disposed and garbage collected, the static field still retains it's value until the Type is unloaded (which is done when its assembly is unloaded, which is done when the AppDomain that assembly is bound to unloads).
-----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-----
|
|
|
|
|
hi...i've always wanted to know what the difference between stack and heap??
when we create a class in C#, say for eg. a class TinCan
TinCan t1;
i came to know that it is created on stack!
Q : Wat is stack? why is it created on statck and not on heap?
then lets say i initiate my reference by creating an object
t1 = new TinCan;
i came to know that this allocates space in memory on the Heap!
Q :What is a heap? why is it now created on heap instead of stack?
Q : Why does C# create the reference on stack and objects on heap?
Q : Whats the difference between stack and heap?
tks a lot for any help!
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
The stack is the linear piece of memory that the operating system and CLR use to maintain the flow of control for a thread. Every thread has its own stack. Each time a method is called the stack grows (traditionally downwards in memory on x86 architectures) as the OS/CLR adds a stackframe.
Each stack frame contains the memory for the functions parameters, it's local variables, and the address to which it will return when complete. (Other more subtle things can be stored on the stack as well, like markers for managed vs unmanaged, assembly evidence, random data that you used stackalloc to reserve space for, etc, but ignore that for now.)
Local variables are created in the stackframe in most languages. This is what enables recursion and scoping of those variables. If you had declared 'struct TinCan' instead of 'class TinCan' the actual value of your object would have been stored on the stack as well, not just a reference to it.
When a method ends, its stackframe is discarded and all data stored there is lost.
The heap is a block of memory managed by the CLR (and allocated out of the OS heap which serves the same purpose for unmanaged processes). From this large block, an application can allocate space for data/objects. The lifetime of an object allocated on the heap is unrelated to the flow of control from method to method. In a managed language like C# the lifetime is controlled by the garbage collection process. In an unmanaged language like C++ the lifetime is controlled by the application which must manually free objects/release data on the heap.
In C# reference types (things declared with 'class') are always allocated on the heap because this permits them to be managed by the garbage collection. Value types (things declared with 'struct') are either allocated on the stack and their lifetime is managed by the flow of execution or they are allocated embedded inside a reference type in which case their lifetime is that of the enclosing object. (A reference to a object is itself a value type and hence follows those rules.)
Hope this helps.
-Blake
|
|
|
|
|
very helpfull indeed...
perhaps if you have some time, you could shed some more light on
Each time a method is called the stack grows (traditionally downwards in memory on x86 architectures) as the OS/CLR adds a stackframe.
and
stackframe....
tks a lot
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
Ut oh... this may require ASCII art, always dangerous. Here goes:
class Example {
int c;
int d = 3;
static int f;
static void Main() {
Example e = new Example();
e.Foo(0);
}
void Foo(int a) {
int b = Bar(a);
c = b;
b += Bar(a, this);
}
int Bar(int a) {
string s = "Test";
return a + 42;
}
}Given the code above, here's what the stack would look like
just as Bar as been called for the second time.
I've oversimplified a _lot_ of things, but this covers the important points.
Stack Heap
Main's +------------------+
Stack- |address of cleanup|
frame |Main.e variable =--+
+------------------+ | Example Object Example Class
Foo's |address of Main | | +------------------+ +---------------+
Stack- |'this' pointer =--+->|address of class |=-->|address of Foo |
frame |Foo.a parameter 0| | |Example.c field 42| |address of Bar |
|Foo.b variable 42| | |Example.d field 3| |Example.f field|
+------------------+ | +------------------+ +---------------+
Bar's |address of Foo | | String Object String Object
Stack- |'this' pointer =--+ +-------------+ +---------------+
frame |Bar.a parameter 42| +-->|various | |string from 1st|
|Bar.s variable =-----+ |string fields| |call to Bar |
+------------------+ +-------------+ +---------------+Sequence of Events:
1) When the code started there was just Main's stackframe.
2) When Foo was called, Foo's stackframe was added below Main's.
3) When Bar was called the first time, a stackframe for it was created below Foo's.
4) When Bar returned the first time this stackframe was removed.
5) When Bar was called a second time, a new stackframe was created. (It happens to be in the same place as the first one, but doesn't have to be.)
Things to Note:
~ Those int values in variables and parameters are stored on the stack.
~ The references to objects of type example are stored on the stack and point into the heap.
~ Instance variables like Example.c and Example.d are stored with the object on the heap.
~ Static variables like Example.f are stored in one place that all instances have a pointer to.
~ The string object created during the first call to Bar is no longer referenced and the garbage collector will clean it up as needed.
-Blake
|
|
|
|
|
wow!!thats a lot of neat info...if you have anymore info pls do lemme know.....tks a lot......really appreciate your help...
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
You are welcome, and no I think that's enough blathering for me for this morning. The best resource for questions of this nature is Don Box's Essential .NET, Volume 1: The Common Language Runtime. I heartily recommend it to anyone who wants to really understand how and why the CLR works.
-Blake
|
|
|
|
|
hi.....
probably a stupid question...but can someone pls tell me how can i get the remainder of a devision in C#???
lets say
3/2
i need to get the reaminder and the quotient seperately...
can anyone help?
tks...
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
|
are u saying if i do
int 1 = 3%2
i will get 1?
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
Yep. That's exactly what he meant. % is a remainder operator in C#, just like / is for division.
Rakesh
Rakesh
|
|
|
|
|
int intRemainder = 0;
Math.DivRem(int1, int2, out intRemainder);
--- or ---
int intRemainder = int1 % int2;
The 2nd way is what Joseph was talking about. The first way is longer however it is using .NET routines so it is safer if you care about cross coding. I would normally always use the second method.
|
|
|
|
|
tks...i was looking for a Math fn....
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
"For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
John 3:16
"Therefore you also be ready, for the Son of Man is coming at an hour you do not expet."
Luke 12:40
|
|
|
|
|
|
I've been using System.Reflection a lot for my custom serializer/deserializer classes, and I'm really digging it. It has made a lot of it pretty easy.
So I've been using
obj.GetType().GetMembers(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance)
to get all the members I care about -- fields and properties.
What's weird, though, is that GetMembers() isn't returning the type's inherited members. I expect it should, and I believe that a few days ago it was. I'm not using any other binding flags, especially not one that would limit the search to just members declared in the immediate type.
Am I doing something wrong, or is the expected usage of GetMembers() that I'd have to iteratively traverse the inheritance tree and GetMembers() of each inherited type?
Thanks,
Arun
|
|
|
|
|
Unless BindingFlags.DeclaredOnly is set, you should be seeing all inheritted, yes. May I ask how you determined that the inherited members weren't being returned? Perhaps surrounding code would be helpful.
-----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-----
|
|
|
|
|
Right. I'm definitely not using BindingFlags.DeclaredOnly. I know that inherited members aren't being returned because they're not being serialized (the output is XML), and I can even check by stepping through with a debugger.
I'm not at work right now, but the code is basically:
<br />
MemberInfo[] members = obj.GetType().GetMembers(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);<br />
<br />
foreach (Member member in members)<br />
{<br />
if (member is FieldInfo)<br />
{<br />
...<br />
}<br />
else if (member is PropertyInfo)<br />
{<br />
...<br />
}<br />
}<br />
Inside each block, I store the member if the conditions are proper. But even if I remove those conditions, I'm still only getting the non-inherited types.
I'm a little concerned that a previous version of my assembly is being used. I'll check for that on Monday, but again, I doubt that's the case since I was even stepping through with VS.
|
|
|
|
|
Well, it looks like I can't get access to private fields of inherited types through GetMembers(). I guess that makes sense. Using Reflector, I see that System.Runtime.Serialization also has to ascend the inheritance tree to get the list of serializable members, so I will, too.
Thanks,
Arun
|
|
|
|
|
hi, 
where can i find all integer values of all WM_... messages?
for example:
int WM_CHAR = 0x0102;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
