[RESOLVED] Value type and reference type!!!

what is the meaning of the reference type?
Actually i want to know what is boxing and unboxing......So i need to clear my concept about the reference type and user type......
Though i searched some documents of google search but i cant clear my concept.......so i posted this question in the forums...

Thank you

Code:

---

the process of changing value types into refference types--Boxing
the process of changing refference types into value types--UnBoxing

---

Can someone explain this to me with the help of a good example?
I search the google but i cant clear my concept.....tats why i am here

A value type is a type whose value is stored in a variable on the stack, e.g. when you do this:

vb.net Code:

Dim var As Integer = 100

the 'var' variable actually contains the value 100. A reference type is a type whose value is stored on the heap while a variable on the stack will contain the memory address of that object, e.g. when you do this:

vb.net Code:

Dim var As Form = New Form

the 'var' variable actually contains a memory address, i.e. a reference to a Form object that resides on the heap.

Note that the stack and the heap are areas in memory that are arranged in different ways to optimise different types of access. Another point to note is that basically classes are reference types and structures are value types.

Boxing is the act of creating an Object variable that contains a reference to a value type, e.g.

vb.net Code:

Dim var As Object = 100

Instead of 'var' containing the value 100 it contains a reference to the value on the heap. In order to use that value you must first unbox it, i.e. assign its value to a variable on the stack. The process of boxing and unboxing is relatively time-consuming and should therefore be avoided if possible. An example of where boxing and unboxing would occur is populating an ArrayList with Integer values. As you retrieve each item it is returned as an Object reference, so you must unbox it to use it. A generic List(Of Integer) is far more efficient because all Integer values are stored in Integer variables, so no boxing or unboxing occurs.

Code:

---

Sub Main()
        Dim var As Object = 100
        Console.WriteLine(var)
        Console.ReadLine()
    End Sub

---

According to you jmc,it contains a reference(Address) to the value on the heap

Then why does it print 100 when i run the application?It might return the address of the heap containing 100.......

Would it be correct to say that you have Option Strict OFF?

Quote:

---

Originally Posted by gautamshaw

Code:

---

Sub Main()
        Dim var As Object = 100
        Console.WriteLine(var)
        Console.ReadLine()
    End Sub

---

According to you jmc,it contains a reference(Address) to the value on the heap

Then why does it print 100 when i run the application?It might return the address of the heap containing 100.......

---

You misunderstand. When you get the value of the variable in code VB knows that you want the value of the object it refers to, not the actual memory address. References are designed to work transparently, i.e. even though the variable on the stack contains a memory address, you can treat it as though it was the object itself. If you could actually get the memory address itself from the variable then that would be a pointer, which you may have heard of. Pointers are very powerful but they can also lead to lots of bugs that can be hard to track down. The use of references is far simpler and plenty powerful enough for most situations. When you need to extra power of pointers you can use them in C# but most hard-core pointer programming occurs in C++, which is much harder to learn than VB.

Ah, I see that it is not necessary for you to have Option Stict OFF and have that line work. If you look in MSDN for what Console.WriteLine(Object) does, you will see that it writes the text representation of the argument. Therefore, it is writing Object.ToString, effectively, which dereferences the address held in var.

If you write in a language such as C, you get to do the dereferencing yourself, but VB hides that from you. When you print var, you don't get the actual contents of var (which would be a 32 bit address on most systems), but instead, you get the contents of the object pointed to by the address in var.

I'm doing this from memory, so I hope I get the technical details correct. I am sure someone will correct me where I step in it! :-)

FYI, I MAY have "Stack" and "Managed Heap" reversed here. Can't look it up right now!! - EDIT: I had it RIGHT!
A. Value Types are just the- they represent a distince area in memory where a discrete VALUE is stored. Value types are of fixed memory size and are stored in the stack, which is a collection of addresses of fixed size (this is where I may get it wrong . . .).

When you make a statement like such:

Code:

---


Dim A as Integer
DIm B as Integer

A = 3
B = A

---

You done the following:

1. Created 2 spaces in memory sufficient to hold 32 bit integer values.
2. Placed a value of 3 in the memory allocation assigned to A
3. Placed a value of 3 in the memory allocation assigned to B by assigning it the same value as the held in A.

The Value of each variable exists discretely in each memory location.

B. Reference Types can be of various sizes. Therefore, they can't be stored in the "Stack" (remember, the stack is a collection of memory allocations of fixed size?). They are stored in the "Managed Heap". Pointers (or "references") to each item on the managed heap are maintained in the stack (Like an Address). Your code uses these pointers in the stack to access objects stored in the managed heap. So when your code uses a reference variable, it is actually using a pointer (or "address" to an memory location in the managed heap).


Say you have created a Class named clsPerson, with a string Property Person.Name

In this case, when you make a statement such as this:

Code:

---


DIm p1 As clsPerson
p1 = New clsPerson
p1.Name = "Jim Morrison"

Dim p2 As Person

p2 = p1

---

In the case above, the p1.Name Property will Return "Jim Morrison", as you would expect. The p2.Name property will ALSO return "Jim Morrison", as you would Iintuitively expect. I believe that both p1 and p2 represent distinct addresses on the Stack. However, now that you have assigned p2 the value of p1, both p1 and p2 point to the SAME LOCATION on the managed heap.

Now COnsider THIS situation:

Code:

---


Dim p1 As clsPerson
Dim p2 As clsPerson

p1 = New clsPerson
p1.Name = "Jim Morrison"

p2 = p1

p2.Name = "Janis Joplin"

---

IN this situation, You have created one new instance of the person Class on the Managed Heap with a pointer p1 on the Stack which references the object, and assigned the Name Property of the object instance a value of "Jim Morrison" again. Next, you created another pointer p2 in the Stack, and pointed it at the same address on the managed heap as that referenced by p1 (when you made the assignement p2 = p1).

Here comes the twist. When you the Assign the Name property of p2 the value "Janis Joplin" you are changing the Name property for the object REFERENCED by Both p1 and p2, such that, if you ran the following code:

Code:

---


MsgBox(P1.Name)
'Will return "Janis Joplin"

MsgBox(p2.Name)
'will ALSO return "Janis Joplin"

---

Because both variables (Pointers on the Stack) reference the SAME OBJECT in memory (an Address on the Managed Heap).

Did that make sense?


Last. If you do THIS:

Code:

---


DIm p1 As New clsPerson
Dim p2 As New clsPerson

p1.Name = "Jim Morrison"
p2.Name = "Janis Joplin"

---

You now have two distinct Person Objects. However, the minute you do THIS again:

Code:

---


p2 = p1

---

You have now pointed both back to "Jim Morrison". (I am not exactly sure what happened to the Object on the Heap referenced by p2 . . . I THINK it has now gone out of scope. This is one of those areas where hopefullly someone can set me straight . . .). -EDIT: I BELIEVE this is why you would Set p2 = Nothing OR p2 = New clsPerson before making the new assignment.

Once again, if you now do THIS:

Code:

---


p2.Name = "Jimi Hendrix"

MsgBox(p1.Name)
MsgBox(p2.Name)

---

Both msgBoxes will now return "Jimi Hendrix"

This can be pretty confusing for a bit, and I will say one last time, I may have some of the details wrong.

Good Luck, and hopefully others who know better than me will come along to help clarify some of this . . .

Uh, those two guys cranked out all that while I was writing. Read what THEY say. I'm about to . . .

Ha! But it sounds like I had the "Stack" and "Heap" correct!

In the below code jmc:

Code:

---

Dim var As Object = 100

---

According to you

Code:

---

In order to use that value you must first unbox it, i.e. assign its value to a variable on the stack

---

But if i can do it directly without unboxing then can i say that:

Code:

---

There is no use of Boxing and Unboxing in vb

---

thanks RunsWithScissors......
But still i have a few queries....
let me ask them one by one......

boxing and unboxing happens automatically... it's not something you need to explicitly do. It just happens. At least in VB... in some languages, like C/C++ and C#, which do support the sue of pointers... it becomes something that is done (or not) more explicitly. Just because you don't have to do it yourself, doesn't mean there's no use for it. It still happens. You just don't see it. Just because you can't see the spark on a spark plug when an engine is running doesn't mean there's no use for the spark plug. It jsut happens.

-tg

Since there is no concept og pointers in VB,then does it means that i cant deal with the memory location of a variable under any situation?
What if i want to identify the address in which a variable is stored?

you can GET to the address... I don't know that you can SET the address...

-tg

How to get the address of a variable then in vb(I cant use the "*").......

You can read the memory address of a variable in VB.Net using the System.Runtime.InteropServices.Marshal class.

right...that's the C pointer usage... not part of VB.

Not sure what it is in .NET, but in VB6 it was ObjPtr() ...

Oh, du'h ... AddressOf XXXXX

-tg

Quote:

---

Originally Posted by techgnome

right...that's the C pointer usage... not part of VB.

Not sure what it is in .NET, but in VB6 it was ObjPtr() ...

Oh, du'h ... AddressOf XXXXX

-tg

---

It's part of the framework... I can't say System.IO.File class is part of VB but I use it all the time in VB.Net ;)

what does System.IO.File have to do with pointers? And AddressOf is part of the VB language... not the FW.

-tg

ok i want to see the address of the integer type variable,then should i do this?

Code:

---

Dim var As Object = 50
        Console.WriteLine(System.Runtime.InteropServices.Marshal(var))

---

even i tried this:

Code:

---

Sub Main()
        Dim var As Object = 50
        Console.WriteLine(System.Runtime.InteropServices.Marshal.AddRef(var))
        Console.ReadLine()

---

this showed me the error:

Code:

---

Specified cast is not valid

---

how to solve this?

Quote:

---

Originally Posted by techgnome

what does System.IO.File have to do with pointers? And AddressOf is part of the VB language... not the FW.

-tg

---

Just a misunderstanding... I thought you were commenting on post#17 about using the Marshal class to read memory address of a variable.

Quote:

---

Originally Posted by gautamshaw

ok i want to see the address of the integer type variable,then should i do this?

---

Try this:

Code:

---

        Dim x As Integer = 10
        Dim pointer As IntPtr = System.Runtime.InteropServices.Marshal.AllocHGlobal(4)
        System.Runtime.InteropServices.Marshal.WriteInt32(pointer, x)
        MessageBox.Show(pointer.ToString)

---

Quote:

---

Originally Posted by stanav

Try this:

Code:

---

        Dim x As Integer = 10
        Dim pointer As IntPtr = System.Runtime.InteropServices.Marshal.AllocHGlobal(4)
        System.Runtime.InteropServices.Marshal.WriteInt32(pointer, x)
        MessageBox.Show(pointer.ToString)

---

---

ok i get the address.......
What does the AllocHGlobal(4) does?
Even what is this code for:

Code:

---

System.Runtime.InteropServices.Marshal.WriteInt32(pointer, x)

---

i need some help!!!

Quote:

---

Originally Posted by techgnome

right...that's the C pointer usage... not part of VB.

Not sure what it is in .NET, but in VB6 it was ObjPtr() ...

Oh, du'h ... AddressOf XXXXX

-tg

---

Huh? I thought it was IntPtr?

Quote:

---

Originally Posted by gautamshaw

i need some help!!!

---

good for you. do you think bumping a thread with bold font and exclamation marks 2 hours after you last posted is going to make people want to help you more? no.

Quote:

---

Originally Posted by gautamshaw

ok i get the address.......
What does the AllocHGlobal(4) does?
Even what is this code for:

Code:

---

System.Runtime.InteropServices.Marshal.WriteInt32(pointer, x)

---

---

When I have that kind of questions, the first thing I would do is to look them up in MSDN library.

Quote:

---

Originally Posted by RunsWithScissors

Ha! But it sounds like I had the "Stack" and "Heap" correct!

---

Mostly. In general, every global variable is created on the heap, while every local object is created on the stack. Technically, VB doesn't need to work that way, but it probably does, if you have the concept of Global vs Local correct. Anytime you use the New keyword, you are probably creating an object on the heap. Further, any value type variable declared in a module is almost certainly created on the heap. Any value type variable declared at form scope will be created as part of the form object, wherever that is created when it is created (though it will probably be on the heap in all cases).

Module variables could be created on the stack, technically, but I can't think of a single advantage to doing so.

Without looking it up, I would say that AllocHGlobal(4) allocates a memory space of four bytes, which is just enough to hold a pointer in 32 bit processes. The second line would then copy the address of x into the memory location labeled 'pointer'.

Thanks!

I think that the OP is getting a bit over-enthusiastic here. Your only going to confuse yourself trying to work out how to determine the memory address of an Integer. What possible reason could you have for doing so? I've never had to do so. That doesn't mean that there's never a reason to but for an application developer the occasions would be rarer than hens teeth.

Quote:

---

Originally Posted by RunsWithScissors

Last. If you do THIS:

Code:

---


DIm p1 As New clsPerson
Dim p2 As New clsPerson

p1.Name = "Jim Morrison"
p2.Name = "Janis Joplin"

---

You now have two distinct Person Objects. However, the minute you do THIS again:

Code:

---


p2 = p1

---

You have now pointed both back to "Jim Morrison". (I am not exactly sure what happened to the Object on the Heap referenced by p2 . . . I THINK it has now gone out of scope. This is one of those areas where hopefullly someone can set me straight . . .). -EDIT: I BELIEVE this is why you would Set p2 = Nothing OR p2 = New clsPerson before making the new assignment.

Once again, if you now do THIS:

Code:

---


p2.Name = "Jimi Hendrix"

MsgBox(p1.Name)
MsgBox(p2.Name)

---

Both msgBoxes will now return "Jimi Hendrix"

This can be pretty confusing for a bit, and I will say one last time, I may have some of the details wrong.

Good Luck, and hopefully others who know better than me will come along to help clarify some of this . . .

---

This creates what is know as a memory leak because there is no way to access the memory to which p2 previously pointed. That memory was not cleared before p2 was pointed to p1.

I beg to differ... that's what the GC is for... to clean up the bits of memory no longer in use. Since the address previously pointed to by p2 is no longer in use, the GC will handle that and clean it up, allowing it to be used.

When p2 gets "rerouted" to a new location, the FW is smart enough to note the old address and mark it for cleanup.

-tg

Quote:

---

You have now pointed both back to "Jim Morrison". (I am not exactly sure what happened to the Object on the Heap referenced by p2 . . . I THINK it has now gone out of scope. This is one of those areas where hopefullly someone can set me straight . . .). -EDIT: I BELIEVE this is why you would Set p2 = Nothing OR p2 = New clsPerson before making the new assignment

---

Yeah. While I was jamming this out from memory, I failed to recognize the scope issue . . .

In reality, of course, I would probably set these objects up to implement IDispose.

However, I don't think a memory leak is created (although I could be wrong); I believe the GC will clean up any objects which are no longer referenced by any other object within the application. However, I am still wrapping my head around the non-deterministic finalization/garabage collection/dispose issue.

Not nearly as easy to cope with as the old-fashioned:

Code:

---


Set p2 = Nothing

---

Nice catch, although I would love to have the memory "Leak" aspect of this confirmed or refuted . . .

Quote:

---

Originally Posted by techgnome

I beg to differ... that's what the GC is for... to clean up the bits of memory no longer in use. Since the address previously pointed to by p2 is no longer in use, the GC will handle that and clean it up, allowing it to be used.

When p2 gets "rerouted" to a new location, the FW is smart enough to note the old address and mark it for cleanup.

-tg

---

Wow. As if by magic, my entreaty is answered, all while I was typing my response.

Thanks Tg. I was hoping I didn't muff that!!

That's not to say that memory leaks in .NET are not possible... they still are... it's just that it's much harder to do now. With VB6, it was a breeze... but mainly because the GC in VB6 was virtually non-existant.

-tg

I think in .NET you just have to watch out for a different type of memory leak to what people traditionally think of as a memory leak. Whilst the GC takes care of 'proper' memory leaks, if you have a reference to an object that you no longer need to use then that is basically a memory leak because the GC cant clean it up. So you still need to be very careful, just not in quite the same way as in languages that dont have the GC... but I guess im not telling anyone anything new here, just giving my thoughts on the matter :)

Quote:

---

Originally Posted by chris128

I think in .NET you just have to watch out for a different type of memory leak to what people traditionally think of as a memory leak. Whilst the GC takes care of 'proper' memory leaks, if you have a reference to an object that you no longer need to use then that is basically a memory leak because the GC cant clean it up. So you still need to be very careful, just not in quite the same way as in languages that dont have the GC... but I guess im not telling anyone anything new here, just giving my thoughts on the matter :)

---

I for one would like any relevan tthoughts on the matter. Thanks. It gets a little confusing, even though I actually get the CONCEPT, the implementation of GC/Disposal etc. is contrary to the way I learned it previously.

I think I have it down now, but that was a very nice explanation, with regard to it being a different paradigm. THis is one of those areas where I often still feel like I am GUESSING as to whether I have done it correctly . . .

in a nutshell the general rule is that if the object has a .Dispose method, call it. Then set it to nothing.

-tg