469,306 Members | 1,894 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,306 developers. It's quick & easy.

difference between private static and public static.

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

how they are allocated and access?.

thanks in advance.

Jan 3 '07 #1
15 33753
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" <tr**************@yahoo.comwrote in message
news:11**********************@k21g2000cwa.googlegr oups.com...
Hi all,
can anyone tell me differene between public static and private static
method.

how they are allocated and access?.

thanks in advance.

Jan 3 '07 #2
I believe that the main difference is that the private static methods are
only accessible by other methods in the class.
Jan 3 '07 #3
Scott M. <s-***@nospam.nospamwrote:
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 oversimplification fails.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 3 '07 #4
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Scott M. <s-***@nospam.nospamwrote:
>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 oversimplification fails.)

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

Willy.

Jan 3 '07 #5
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 oversimplification fails.)

No, static variable are *never* allocated on the stack, they are allocated on a per
"Application Domain" special heap (called the HighFrequencyHeap). 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

Jan 3 '07 #6
Jon Skeet [C# MVP] <sk***@pobox.comwrote:
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 oversimplification fails.)
No, static variable are *never* allocated on the stack, they are allocated on a per
"Application Domain" special heap (called the HighFrequencyHeap). 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 3 '07 #7
Mark R. Dawson <Ma*********@discussions.microsoft.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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 3 '07 #8
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Mark R. Dawson <Ma*********@discussions.microsoft.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 - <sk***@pobox.com>
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 HighFrequencyHeap, 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 (HighFrequencyHeap) 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(int), 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\netfx\Junk\objlayout.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.

Jan 4 '07 #9
Jon, the article is wrong.
static fields whatever their type are always stored on the
HighFrequencyHeap, 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.
Jan 4 '07 #10
Scott M. <s-***@nospam.nospamwrote:
Jon, the article is wrong.
static fields whatever their type are always stored on the
HighFrequencyHeap, 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 4 '07 #11
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
static fields whatever their type are always stored on the
HighFrequencyHeap, 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 4 '07 #12
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP***********************@msnews.microsoft.co m...
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
>static fields whatever their type are always stored on the
HighFrequencyHeap, 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.
Jan 4 '07 #13
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]" <sk***@pobox.comwrote in message
news:MP***********************@msnews.microsoft.co m...
Scott M. <s-***@nospam.nospamwrote:
Jon, the article is wrong.
static fields whatever their type are always stored on the
HighFrequencyHeap, 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jan 4 '07 #14
Scott M. <s-***@nospam.nospamwrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 4 '07 #15
Static Data is a shared data
It is an Class level data
The public & Private It's simply a matter of accessibility.
Public static members can be accessable to any assembly where the
static member is declared. Private static members can only be
accessible
from within the class.

Jan 18 '07 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Petra Neumann | last post: by
8 posts views Thread by Aman | last post: by
2 posts views Thread by Jason Huang | last post: by
4 posts views Thread by sviau | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.