Object Data Type?

[Arpan]

The .NET Framework 2.0 documentation states that

An Object variable always holds a pointer to the data, never the data
itself.

Now w.r.t. the following ASP.NET code snippet, can someone please
explain me what does the above statement mean?

<script runat="server">
Class Clock
Public Second As Integer
Public Minute As Integer
Public Hour As Integer

Sub SetTime(ByVal intSec As Integer, ByVal intMin As Integer,
ByVal intHour As Integer)
Second = intSec
Minute = intMin
Hour = intHour
End Sub
End Class

Sub Page_Load(ByVal obj As Object, ByVal ea As EventArgs)
Dim objClock As New Clock

objClock.Second = 45
objClock.SetTime(25, 15, 8)
End Sub
</script>

Thanks,

Arpan

 

[Karl Seguin [MVP]]

I'm not sure what ur confused about?

objClock is a variable. In all languages that I know about, variables can be
stored in 1 of 2 places - the stack of the heap. The stack is considerably
smaller and quicker than the heap. In .NET all value types (structs, ints,
booleans, char, ...) are stored on the stack. All other types (object types)
are stored on the heap. To access values in the heap you need to know the
start address - this start address is known as a pointer. The pointer value
itself is a 32 bit value (for 32 bit systems) which is stored on the stack.
Think about it, you can have a string (or another object) that represents
200megs of data, but your pointer only uses 1 slot in your stack.


So far, everything's straightforward. Question is, what about value types
that are part of classes, like your 3 public fields (Second, Minute and
Hour)? Well, even though they are value types, they'll be stored on the heap
as part of the class. Only local value types end up really stored on the
stack - it's a scope issue at that point.

Karl

P.S. - Hungarian notation is (rightfully) frowned upon, what value does
adding "obj" to your objClock variable give you?

 

[Arpan]

Thanks, Karl, for your help but I still have some doubts in my mind.

First of all, what is the difference between stack & heap?

You say that to access a value in the heap, you need to know the start
address but the start address of WHAT needs to be known to access
values in a heap? Moreover, how does one get that start address?

Think about it, you can have a string (or another object) that represents
200megs of data, but your pointer only uses 1 slot in your stack

I couldn't exactly follow the above statement. Could you please throw
some more light on that statement?

P.S. - Hungarian notation is (rightfully) frowned upon, what value does
adding "obj" to your objClock variable give you?

Isn't it a good practice to use an abbreviation of the variable's data
type as a prefix not only to keep track of which variable is used for
which purpose but also for enhancing code readability like intCount
(Integer), strName (String), blnAsk (Boolean) etc.?

Thanks once again & sorry for the trouble......

Arpan

 

[Karl Seguin [MVP]]

Arpan:
Lemme try to provide more answers.

First, about Hungarian Notation, it used to be the preferred notation, but
with the release of .NET, Microsoft moved away from the practice. First,
_everything_ in .NET inherits from System.Object, so shoudln't everything
start with "obj"? Secondly, your variables should be named meaningfully
enough that the extra information adds no value. For example, simply naming
your variable "clock" gives us a very good idea of what it is. Finally,
there are far more effective tricks (or refactorings) to make your code more
readable and maintainable. Of course, personal coding style is entirely up
to you, so whatever feels best for you. For more information, I suggest you
check out the results from this google search:
http://www.google.ca/search?hs=46c&...+not+use+hungarian+notation&btnG=Search&meta=


I found this very good site which might help you better visualize stack and
heap usage:
http://www.c-sharpcorner.com/Upload...rticleID=9adb0e3c-b3f6-40b5-98b5-413b6d348b91

The biggest difference between the stack and the heap is their scope. The
stack is used to store local variables - when you enter a function, a new
stack is created just for that function, and when you exit it, all values
are removed from it.

The "new" operator returns the start address, or the "pointer". In
languages such as C and C++, this is much easier to observe, but it's
nonetheless true for C# too. When you do "new Clock();", the right amount of
room will be found on the heap (it knows how much room each object takes),
once found it'll be allocated for the class, and the pointer (start address)
will be placed on the stack, where it'll be returned and assigned to your
variable. It's the start address of where the object is located in the
heap - but I don't know exactly how memory is allocated - I believe it works
by offsets.

My point about the size is simply that pointers tend to be much smaller than
the data they point to. For example, your "clock" variable contains a 32bit
pointer, which points to 50Kb (for example) of data (your actual clock
object). Passing around your pointer (ie, as a function parameter) is much
more efficient than passing around 50kb of data.

I encourage further questions - I think this is fundamental stuff every
programmer ought to know. That said, i hope you realize that C# takes care
of managing all of this for you. It is possible to deal directly with
ointers via "unsafe" code, or using C++, but one of the beautiful things
about C#/VB.NET/Java is that it's taken care of for you ...and rather well.

Karl

 

[Arpan]

I really appreciate you, Karl, for all the help you have extended
towards me. Thank you very very much.

I had been to the URL you suggested which highlights the differences
between Stack & Heap. The article has been really helpful (more so
because of the pictorial representations) & has clarified a lot of my
doubts regarding memory management. However, a few doubts still persist
in my mind.

Towards the end, the article states that when we are using Reference
Types, we are dealing with POINTERS TO THE TYPE, NOT THE THING ITSELF.
This is described using the following 2 examples:

Example1:

public int ReturnValue()
{
int x = 3;
int y = x;
y = 4;
return x;
}

This will return the value of x as 3.......no problem till this point.

Example2:

public class MyInt
{
public int MyValue;
}

public int ReturnValue2()
{
MyInt x = new MyInt();
x.MyValue = 3;
MyInt y = new MyInt();
y = x;
y.MyValue = 4;
return x.MyValue;
}

First of all, w.r.t. the 2nd example, what is "TYPE" & what is "THING"
in the line "......POINTER TO THE TYPE, NOT THE THING ITSELF"?

Secondly, the 2nd example will return the value of x as 4 since both x
& y point to the same object in the Heap. This is what I couldn't
understand. Why is the value of x in the 2nd example 4 (& not 3 as in
the 1st example)? Is it because the variable "MyValue" in the class
"MyInt" can hold only 1 value & since y accesses the variable "MyValue"
AFTER x, the return value of x is 4 & not 3? Kindly please explain me
this.

Thanks once again,

Regards,

Arpan

 

[Arpan]

Karl, as stated in my very first post, the .NET Framework 2.0
documentation states that

An Object variable always holds a pointer to the data, never the data
itself.

Now w.r.t. the Clock example (in my first post), the OBJECT VARIABLE is
"objClock" (let's keep the notation aspect aside for the moment) but
what is the DATA here? Is it the class named "Clock"?

Arpan

 

[Karl Seguin [MVP]]

Ok, first example is straightforward, you are dealing with value types.

In the 2nd example..

MyInt x = new MyInt();
creates space on the heap, and returns a pointer, say 0x000001

x.MyValue = 3;
assigns a value to the object contained on the heap and pointed to by "x"

MyInt y = new MyInt();
creates space on the heap, and returns a pointer, say 0x000002

y = x;
This is the important one, since we are dealing with pointers, assigns
0x000001 to y. Both y and x now point to the same object. The object that
exists (or starts) at 0x000002 is now orphaned and will be garbage collected
at some point

y.MyValue = 4;
same as doing x.MyValue = 4 because both x and y point to the same address


I guess the "type" is the start of the address space on the heap as opposed
to the address itself. I think the point that they are trying to make is
that y = x doesn't create a whole new copy of x, but rather makes x and y
point to the same thing.


here's some more info

MyInt x = new MyInt();
MyInt y = new MyInt();
MyInt z = x;
x == y //false
x == z //true
The equality operator (==) for object types checks to see if two objects
point to the same address. Strings are a special case (in many ways) - the
actual value will be compared, even though they are object types. You can
always overload the equality operator to change this behaviour..but that's
not overly relevant to the discussion.

Karl

 

[Karl Seguin [MVP]]

Again, I think the spirit of what's being said is that objClock is merely a
pointer to the data, and not the data itself. It's relevent with respect to
passing the variable around to a function or doing other types of
assignemtns (like your previous post asked about).

For example:

int x = 5;

x is actually the value 5. As we saw, if you do y = x, then y takes on the
value.

If you do:

int x = 5;
object y = x;


..NET will do something called "boxing" which means a value is moved from the
stack onto the heap (there's a performance hit associated with that). At
this point, x and y are very different. y points to a 32 bit memory space
that contains the value 5, x IS the value 5. Depending on what you are
doing, this might be totally transparent (i.e., the difference between x and
y is only difference when talking about it, not when dealing with them). If
you do:


int a = x;
a = 3;

x is still 5

if you do

object b = x;
b = 3
x is now 3.

karl