Static/Shared Members

  • Thread starter Thread starter Scott M.
  • Start date Start date
S

Scott M.

When a type member is declared as static (C#) or Shared (VB .NET), does the
CLR have to load one (1) of those types into memory in order to utilize the
type?
 
Scott M. said:
When a type member is declared as static (C#) or Shared (VB .NET), does the
CLR have to load one (1) of those types into memory in order to utilize the
type?
Click to expand...

It loads the type, yes - but it doesn't need to create any *instances*
of the type.
 
Say there is a shared/static property. How does the CLR set/get that value
if there isn't at least one "instance" in memory. I can understand that you
could execute a method from just the type library, but to hold data, don't
you need an instnace?
 
Scott M. said:
Say there is a shared/static property. How does the CLR set/get that value
if there isn't at least one "instance" in memory. I can understand that you
could execute a method from just the type library, but to hold data, don't
you need an instnace?
Click to expand...

The data isn't stored with instances, basically. No, you don't need an
instance of the type to store data. Effectively there are two areas
where data is kept - one for instances (per instance) and one for types
(per type).

If the data for static members was stored with the instances, it would
be horrendous - you'd end up with each instance having to have a copy
of all the current static data, and copying it around everywhere.

Note that it's quite possible to have types which *can't* be
instantiated, but still have static data.
 
Jon Skeet said:
The data isn't stored with instances, basically. No, you don't need an
instance of the type to store data. Effectively there are two areas
where data is kept - one for instances (per instance) and one for types
(per type).
Click to expand...

What is that area called?
If the data for static members was stored with the instances, it would
be horrendous - you'd end up with each instance having to have a copy
of all the current static data, and copying it around everywhere.
Click to expand...

I was thinking more along the lines that, rather than the data being stored
with instances (as you describe), one (1) instance is created that all other
types of the same type utilize, thereby avoiding the copies you describe.
 
Scott M. said:
What is that area called?
Click to expand...

Well, it's on the heap, although part of a special heap whose name I
can't remember off the topc of my head. The important thing is that
it's logically distinct - the data for the static members isn't stored
alongside any particular instance.

That's why I don't like the VB term "Shared" - it makes it sounds like
it's shared between instances, rather than being specific to the type
and not to *any* instance. The C# term "static" is also far from
informative, however, and raises other issues :(
I was thinking more along the lines that, rather than the data being stored
with instances (as you describe), one (1) instance is created that all other
types of the same type utilize, thereby avoiding the copies you describe.
Click to expand...

No, there's no need to have any instances for that - it would be messy
and inelegant. Why create an instance at all if you're not going to use
the instance data in it, and *are* going to have extra data just for
that object?
 
Back
Top