difference between private static and public static.

[archana]

Hi all,
can anyone tell me differene between public static and private static
method.

how they are allocated and access?.

thanks in advance.

[Scott M.]

Re: difference between private static and public static.

It's simply a matter of accessibility. Public static members will be
available to any assembly that has a reference to the assembly where the
static member is declared.. Private static members will only be accessible
from within the class. You access them via the type, rather than making
instances of the type they are declared in. They are allocated on the stack
or heap, depending on whether they are value types or reference types (as
all types are).


"archana" <trialproduct20 04@yahoo.comwro te in message
news:1167800905 .367219.164820@ k21g2000cwa.goo glegroups.com.. .

Hi all,
can anyone tell me differene between public static and private static
method.
>
how they are allocated and access?.
>
thanks in advance.
>

[=?Utf-8?B?WE9S?=]

RE: difference between private static and public static.

I believe that the main difference is that the private static methods are
only accessible by other methods in the class.

[Jon Skeet [C# MVP]]

Re: difference between private static and public static.

Scott M. <s-mar@nospam.nosp amwrote:

It's simply a matter of accessibility. Public static members will be
available to any assembly that has a reference to the assembly where the
static member is declared..

Yes.

Private static members will only be accessible
from within the class.

And nested classes within that class.

You access them via the type, rather than making
instances of the type they are declared in. They are allocated on the stack
or heap, depending on whether they are value types or reference types (as
all types are).

No - static variables are *always* allocated on the stack, whether
they're value types or reference types. (Just another example of where
the oversimplificat ion fails.)

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

Re: difference between private static and public static.

"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.20056e 311aee9fd398d72 f@msnews.micros oft.com...

Scott M. <s-mar@nospam.nosp amwrote:

>It's simply a matter of accessibility. Public static members will be
>available to any assembly that has a reference to the assembly where the
>static member is declared..

>
Yes.
>

>Private static members will only be accessible
>from within the class.

>
And nested classes within that class.
>

>You access them via the type, rather than making
>instances of the type they are declared in. They are allocated on the stack
>or heap, depending on whether they are value types or reference types (as
>all types are).

>
No - static variables are *always* allocated on the stack, whether
they're value types or reference types. (Just another example of where
the oversimplificat ion fails.)

No, static variable are *never* allocated on the stack, they are allocated on a per
"Applicatio n Domain" special heap (called the HighFrequencyHe ap). How could they ever be
shared when stack allocated?

Willy.

[Jon Skeet [C# MVP]]

Re: difference between private static and public static.

Willy Denoyette [MVP] wrote:

No - static variables are *always* allocated on the stack, whether
they're value types or reference types. (Just another example of where
the oversimplificat ion fails.)

>
No, static variable are *never* allocated on the stack, they are allocated on a per
"Applicatio n Domain" special heap (called the HighFrequencyHe ap). How could they ever be
shared when stack allocated?

Doh doh doh, that is of course exactly what I meant :) Fortunately the
referenced page has it the right way round - although it needs updating
a bit to handle local variables captured by anonymous methods...

Jon

[Jon Skeet [C# MVP]]

Re: difference between private static and public static.

Jon Skeet [C# MVP] <skeet@pobox.co mwrote:

Willy Denoyette [MVP] wrote:

No - static variables are *always* allocated on the stack, whether
they're value types or reference types. (Just another example of where
the oversimplificat ion fails.)

No, static variable are *never* allocated on the stack, they are allocated on a per
"Applicatio n Domain" special heap (called the HighFrequencyHe ap). How could they ever be
shared when stack allocated?

>
Doh doh doh, that is of course exactly what I meant :) Fortunately the
referenced page has it the right way round - although it needs updating
a bit to handle local variables captured by anonymous methods...

Except it turns out I didn't even reference the page. I need more
sleep!

http://www.pobox.com/~skeet/csharp/memory.html

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Re: difference between private static and public static.

Mark R. Dawson <MarkRDawson@di scussions.micro soft.comwrote:

Hi Jon,
in the article there is the comment:
>
"Every static variable is stored on the heap, regardless of whether it's
declared within a reference type or a value type. There is only one slot in
total no matter how many instances are created. (There don't need to be any
instances created for that one slot to exist though.) Note that this heap is
separate from the normal garbage collected heap - it's known as a "high
frequency heap", and there's one per application domain. "
>
However, from reading this article:

http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/

>
It makes the comment that only primitive static types will be stored on the
high frequency heap, whereas static value types and reference types are still
stored on the normal GC Heap.

Ooh, interesting. I'll look into it - thanks very much. The stuff about
the high frequency heap was going on what Willy has said in the past :)

I suspect that it's better for the sake of simplicity to remove the
reference to the high frequency heap and just refer to that article...

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

Re: difference between private static and public static.

"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.200634 3d7e810b8398d73 2@msnews.micros oft.com...

Mark R. Dawson <MarkRDawson@di scussions.micro soft.comwrote:

>Hi Jon,
> in the article there is the comment:
>>
>"Every static variable is stored on the heap, regardless of whether it's
>declared within a reference type or a value type. There is only one slot in
>total no matter how many instances are created. (There don't need to be any
>instances created for that one slot to exist though.) Note that this heap is
>separate from the normal garbage collected heap - it's known as a "high
>frequency heap", and there's one per application domain. "
>>
>However, from reading this article:
>http://msdn.microsoft.com/msdnmag/is...5/JITCompiler/
>>
>It makes the comment that only primitive static types will be stored on the
>high frequency heap, whereas static value types and reference types are still
>stored on the normal GC Heap.

>
Ooh, interesting. I'll look into it - thanks very much. The stuff about
the high frequency heap was going on what Willy has said in the past :)
>
I suspect that it's better for the sake of simplicity to remove the
reference to the high frequency heap and just refer to that article...
>
--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jon, the article is wrong.
static fields whatever their type are always stored on the HighFrequencyHe ap, they can never
be members of object instances , so they are NEVER on the GC heap.

Consider following sample and my anotations.
....
class C
{
public int sc = 0;
public static S s;
}
public struct S
{
public int w;
public static long l;
}
class Program
{
static int v = 123;
static void Main()

{
S s1 = new S(); [1]
v = 128; [2]
C c1 = new C(); [3]
C.s = new S(); [4]
C c2 = new C(); [5]
S.l = 0xffffffffff; [6]
C.s.w = 255; [7]
s1.w = 123; [8]
}
}

[1] allocates s1 on the stack. But finally what get's on the stack is only the contents of
S.w, S.l ends on the (HighFrequencyH eap) HFH, and stays there until the AD unloads, s1 stays
on the stack until the stack unwinds.

[2] That's an easy one, v is on the HFH, and is assigned the value 128.

[3] c1 is a reference to a type C on the GC heap. It's 's' variable however, gets stored on
the HFH, and stay's there until the AD unloads. Note, it's size is 12 bytes only, that is
the header+sizeof(i nt), assuming X86 here. the instance gets freed when GC'd.

[4] Now it gets really complicated, the variable C.s is static, so, it's on the HFH, the
value pointed to by C.s gets stored on the GC heap, but there you'll find only the field
S.w, the static field S.l gets stored on the HFH.

[5] Here I create a new instance of C. Here c2 points to an instance of C on the GC heap.
But, it's "s" field is on the HFH, actually it's the same field as c1.S (that is same
address, so same value).

[6] assign a large value to S.l (on the HFH see 1).

[7] C.s.w is assigned a value 255, this value is on the GC heap see [4]

[8] s1.w is assigned the value 123, this value ends on the stack (see 1)

You can inspect this all, by using a native debugger like Windbg.exe, take care however when
using the SOS .DLL extension, this one gives you the wrong impression that static's are
instance members and stored in-line on the GC heap, but if you watch carefully you'll see
that effectively the static's are stored elsewhere (this is quite obvious isn't it, how
could they otherwise survive a GC sweep?).

To illustrate this last point, consider the debugger SOS output...

0:000!do 029b19cc
Name: Willys.C
MethodTable: 00103198
EEClass: 00101844
Size: 12(0xc) bytes
(C:\Develop\net fx\Junk\objlayo ut.exe)
Fields:
MT Field Offset Type VT Attr Value Name
790ff7f0 4000001 4 System.Int32 0 instance 0 sc
00103124 4000002 4 Willys.S 1 static 029b19a4 s
0:000dd 029b19cc
029b19cc 00103198 00000000 00000000 00103198

!do dumps the object at address 029b19cc (the GC heap), the output makes you believe that
the static field is part of the instance, well it's NOT and I think the author of the
article in MSDN Mag made the mistake in believing it was.
Note the size (12 bytes), that includes the sync#, MT pointer and an instance field 'sc'.
Note also the next field, see it's offset.... and it's attribute (static) so you see it's
not part of the instance...
notice also the fields value (029b19a4 ) again this is a pointer to the GC heap..
the "dd" command dumps the real contents of the address (029b19cc ), which is the real
object contents (less the sync# field), the first DWORD (00103198 ) is the MT pointer and
the next DWORD (00000000) is the value of sc, and that's it.

Willy.

[Scott M.]

Re: difference between private static and public static.

Jon, the article is wrong.

static fields whatever their type are always stored on the
HighFrequencyHe ap, they can never be members of object instances , so they
are NEVER on the GC heap.

I don't know about C#, but in VB.NET you can call a "shared" member
(VB.NET's version of C#'s "static") on an instance as well as the type.

[Jon Skeet [C# MVP]]

Re: difference between private static and public static.

Scott M. <s-mar@nospam.nosp amwrote:

Jon, the article is wrong.
static fields whatever their type are always stored on the
HighFrequencyHe ap, they can never be members of object instances , so they
are NEVER on the GC heap.

>
I don't know about C#, but in VB.NET you can call a "shared" member
(VB.NET's version of C#'s "static") on an instance as well as the type.

Yes, but that doesn't change where it's stored.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Re: difference between private static and public static.

Willy Denoyette [MVP] <willy.denoyett e@telenet.bewro te:

static fields whatever their type are always stored on the
HighFrequencyHe ap, they can never
be members of object instances , so they are NEVER on the GC heap.

Well, looking at the article closely, I don't think it actually says
they can be on the normal GC heap. It just says that they can be in the
HandleTable instead of the MethodTable (with a reference from the
MethodTable). It doesn't go into details about the HandleTable,
unfortunately.

Of course, I may have misread the MSDN article - is there any specific
statement in it that you consider incorrect?

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

Re: difference between private static and public static.

"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.2006bc 8fb84519898d734 @msnews.microso ft.com...

Willy Denoyette [MVP] <willy.denoyett e@telenet.bewro te:

>static fields whatever their type are always stored on the
>HighFrequencyH eap, they can never
>be members of object instances , so they are NEVER on the GC heap.

>
Well, looking at the article closely, I don't think it actually says
they can be on the normal GC heap. It just says that they can be in the
HandleTable instead of the MethodTable (with a reference from the
MethodTable). It doesn't go into details about the HandleTable,
unfortunately.
>
Of course, I may have misread the MSDN article - is there any specific
statement in it that you consider incorrect?

Actually no I don't, actually the article is right in mentioning the HANDLE table.
Unfortunately the article is based on the shared code CLI source, which is actually not what
the retail version of the CLR looks like. The GC and the JIT for instance are completely
different, but you are right, it doesn't say it's on the GC heap, while actually it is, be
it on the LOH and not on the Generational heap (gen0, 1 and 2).
Now, I've done some more research to find out where static fields, holding references to
boxed value types, actually have their roots.

Reconsider the previous posted sample:

<snip>
class C
{
public int sc = 0;
public static S s;
}
public struct S
{
public int w;
public static long l;
}
....
class Program {
static int v = 123;
static void Main()
{
S s1 = new S();
v = 128;
C c = new C();
C.s = new S();
C c2 = new C();
S.l = 0xffffffffff;
C.s.w = 255;
s1.w = 123;
A ---->
</snip>

What we have at A is (I wish I had chosen some meaningful names):
1) v is on the HFH holding the value 128.
2) S.l is on the HFH holding the value 0xffffffff.
3) C.s is on the LOH pointing to S boxed on the GC heap, with C.s.w holding the value 255.
4) s1.w is on the stack holding the value 123.

What's important is 3), here the static field reference 's', pointing to the boxed instance
of S, is on the LOH.
Now, why is this on the LOH?
The (Pinned!) *Handle table* is actually an object[], and this one is allocated on the LOH
(at the very beginning) with an initial size of 1020 elements. My guess is that it is
initially created on the LOH and not on the generational heap, such that the GC (and the
JIT) doesn't need to track it's actual size and location and so, he can keep it "fixed"
wihout disturbing the GC.
Note that here the static 's' variable is just an entry in this array, which is actually the
root of the boxed S instance.

Conclusion: all static's are in the HFH unless they hold references to boxed value or
reference types, in which case they are in the handle table which is on the LOH. Note that
all this is not documented, so it's really an implementation detail that might change with
the CLR version.

Willy.

[Scott M.]

Re: difference between private static and public static.

I didn't say that it did. I was responding to Willy's message about static
members not being members of an instance.


"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.2006bb b41cd4e0398d733 @msnews.microso ft.com...

Scott M. <s-mar@nospam.nosp amwrote:

Jon, the article is wrong.
static fields whatever their type are always stored on the
HighFrequencyHe ap, they can never be members of object instances , so
they
are NEVER on the GC heap.

>>
>I don't know about C#, but in VB.NET you can call a "shared" member
>(VB.NET's version of C#'s "static") on an instance as well as the type.

>
Yes, but that doesn't change where it's stored.
>
--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Re: difference between private static and public static.

Scott M. <s-mar@nospam.nosp amwrote:

I didn't say that it did. I was responding to Willy's message about static
members not being members of an instance.

They're not members of an instance. Just because you can access them as
if they were doesn't make them members.

(FWIW, I think it's a pity that VB.NET *does* allow you to do that.
Java allows the same thing, and it's a potential source of bugs because
it looks like you're doing something instance-specific when you're
not.)

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too