Casting in VB.Net and C#

[Ken Allen]

I am relatively new to .Net, but have been using VB and C/C++ for years.

One of the drawbacks with VB6 and earlier was the difficulty in casting a
'record' to a different 'shape' so one could perform different manipulations
on it. For example, I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes so that I could perform a checksum
calculation on the contents. Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information. This was also very difficult in VB6.

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?

-Ken

[Jan Tielens]

In VB.NET you can use:
- CType
- DirectCast

In C# you can use:
- (typeName)

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan
"Ken Allen" <ke******@sympatico.ca> wrote in message
news:ee**************@tk2msftngp13.phx.gbl...

I am relatively new to .Net, but have been using VB and C/C++ for years.

One of the drawbacks with VB6 and earlier was the difficulty in casting a
'record' to a different 'shape' so one could perform different manipulations on it. For example, I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes so that I could perform a checksum
calculation on the contents. Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information. This was also very difficult in VB6.

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?

-Ken

[One Handed Man [ OHM# ]]

Just to clarify the difference between CType and DirectCast.

DirectCast can only be used on reference types
and they have to be the same type. Whereas, CType
can be used on both Value Types and Reference Types
where the casting is permissable.

DirectCast is faster at runtime than CType.

Regards - OHM#
Jan Tielens wrote:

In VB.NET you can use:
- CType
- DirectCast

In C# you can use:
- (typeName)
"Ken Allen" <ke******@sympatico.ca> wrote in message
news:ee**************@tk2msftngp13.phx.gbl...

I am relatively new to .Net, but have been using VB and C/C++ for
years.

One of the drawbacks with VB6 and earlier was the difficulty in
casting a 'record' to a different 'shape' so one could perform
different manipulations on it. For example, I have a complex data
structure, which I can represent in a VB6 TYPE declaration, but I
cannot easily convert that to a fixed length array of unsigned bytes
so that I could perform a checksum calculation on the contents.
Another case is where a read a buffer from a file and then wish to
interpret the contents based on some header information. This was
also very difficult in VB6.

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?

-Ken

Regards - OHM# On**********@BTInternet.com

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

Just to clarify the difference between CType and DirectCast.

DirectCast can only be used on reference types
and they have to be the same type. Whereas, CType
can be used on both Value Types and Reference Types
where the casting is permissable.
Only a remark: DirectCast can also be used with value types when the object
is boxed:

Dim o As Object
Dim i As Integer
o = 17I
i = DirectCast(o, Integer)
@Ken:
DirectCast performs type casting whereas CType can perform type casting
_and_ type conversion. Type casting only changes the type of the reference,
but it does not create a new object. Type conversion does create a new
object.
DirectCast is faster at runtime than CType.

Under which circumstances? I read this also before but I could not reproduce
it. The speed was equal.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Ken,

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)? Personally that is the key word "error prone"! .NET goes out of its way to
avoid such error prone code!
One of the drawbacks with VB6 and earlier was the difficulty in casting a
'record' to a different 'shape' so one could perform different manipulations on it. Luckily VB6 & VB.NET have type safety! I consider this a major benefit not a
drawback!

Note a VB6 Type is a VB.NET Structure, however I would recommend using a
Class instead.
I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes so that I could perform a checksum
calculation on the contents. I would "serialize" the structure to a MemoryStream using a BinaryWriter. I
would then calculate the checksum on the MemoryStream. Both MemoryStream &
BinaryWriter are in the System.IO namespace. Alternatively you can use
System.GitConverter.GetBytes to get byte arrays for individual members
however the BinaryWriter & MemoryStream makes this significantly easier!
Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information. I would use an BinaryReader to read the header information interpreting &
"deserializing" as I go. BinaryReader is also in the System.IO namespace.

By "serialize" and "deserialize" I mean I would implement custom routines
that would convert an object to & from a binary format using the
BinaryReader & BinaryWriter classes similar to what is described in the
following article:

http://msdn.microsoft.com/library/de...rp09182003.asp

Note the samples are C#, with your C++ background you should be able to
convert them.

An alternative to the BinaryReader & BinaryWriter is the
System.Runtime.InteropSerivces.Marshal class. Check out the StructureToPtr &
PtrToStructure methods along with the Copy or Read methods. Although the
method is StructureToPtr you can use them with either a VB.NET Class or a
Structure...

Hope this helps
Jay

"Ken Allen" <ke******@sympatico.ca> wrote in message
news:ee******************@tk2msftngp13.phx.gbl... I am relatively new to .Net, but have been using VB and C/C++ for years.

One of the drawbacks with VB6 and earlier was the difficulty in casting a
'record' to a different 'shape' so one could perform different manipulations on it. For example, I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes so that I could perform a checksum
calculation on the contents. Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information. This was also very difficult in VB6.

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?

-Ken

[One Handed Man [ OHM# ]]

But its primary Type is still Object

Regards - OHM

Armin Zingler wrote:

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

Just to clarify the difference between CType and DirectCast.

DirectCast can only be used on reference types
and they have to be the same type. Whereas, CType
can be used on both Value Types and Reference Types
where the casting is permissable.

Only a remark: DirectCast can also be used with value types when the
object is boxed:

Dim o As Object
Dim i As Integer
o = 17I
i = DirectCast(o, Integer)
@Ken:
DirectCast performs type casting whereas CType can perform type
casting _and_ type conversion. Type casting only changes the type of
the reference, but it does not create a new object. Type conversion
does create a new object.

DirectCast is faster at runtime than CType.

Under which circumstances? I read this also before but I could not
reproduce it. The speed was equal.

Regards - OHM# On**********@BTInternet.com

[One Handed Man [ OHM# ]]

Everytime you post, I realise how little I know.

Regards - OHM#
Jay B. Harlow [MVP - Outlook] wrote:

Ken,

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)? Personally that is the key word "error prone"! .NET goes out of its
way to avoid such error prone code!

One of the drawbacks with VB6 and earlier was the difficulty in
casting a 'record' to a different 'shape' so one could perform
different manipulations on it.

Luckily VB6 & VB.NET have type safety! I consider this a major
benefit not a drawback!

Note a VB6 Type is a VB.NET Structure, however I would recommend
using a Class instead.

I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a
fixed length array of unsigned bytes so that I could perform a
checksum calculation on the contents.

I would "serialize" the structure to a MemoryStream using a
BinaryWriter. I would then calculate the checksum on the
MemoryStream. Both MemoryStream & BinaryWriter are in the System.IO
namespace. Alternatively you can use System.GitConverter.GetBytes to
get byte arrays for individual members however the BinaryWriter &
MemoryStream makes this significantly easier!

Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information.

I would use an BinaryReader to read the header information
interpreting & "deserializing" as I go. BinaryReader is also in the
System.IO namespace.

By "serialize" and "deserialize" I mean I would implement custom
routines that would convert an object to & from a binary format using
the BinaryReader & BinaryWriter classes similar to what is described
in the following article:

http://msdn.microsoft.com/library/de...rp09182003.asp
Note the samples are C#, with your C++ background you should be able
to convert them.

An alternative to the BinaryReader & BinaryWriter is the
System.Runtime.InteropSerivces.Marshal class. Check out the
StructureToPtr & PtrToStructure methods along with the Copy or Read
methods. Although the method is StructureToPtr you can use them with
either a VB.NET Class or a Structure...

Hope this helps
Jay

"Ken Allen" <ke******@sympatico.ca> wrote in message
news:ee******************@tk2msftngp13.phx.gbl...

I am relatively new to .Net, but have been using VB and C/C++ for
years.

One of the drawbacks with VB6 and earlier was the difficulty in
casting a 'record' to a different 'shape' so one could perform
different manipulations on it. For example, I have a complex data
structure, which I can represent in a VB6 TYPE declaration, but I
cannot easily convert that to a fixed length array of unsigned bytes
so that I could perform a checksum calculation on the contents.
Another case is where a read a buffer from a file and then wish to
interpret the contents based on some header information. This was
also very difficult in VB6.

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?

-Ken

Regards - OHM# On**********@BTInternet.com

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

But its primary Type is still Object

Type of what? After DirectCast it is Integer.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[One Handed Man [ OHM# ]]

Sorry, but when you assigned it 17i you already cast it. So the types are
the same by the time it gets to direct cast.

However, I am a little confused over this, because after casting occurs 'o'
still maintains the Type 'Object' in the Locals window although the Object
pointed to is of Type Integer.

Can you adequately explain this to me ?

Regards - OHM#
Armin Zingler wrote:

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

But its primary Type is still Object

Type of what? After DirectCast it is Integer.

Regards - OHM# On**********@BTInternet.com

[Jay B. Harlow [MVP - Outlook]]

Doh!

System.GitConverter.GetBytes to get byte arrays for individual members That should be System.BitConverter.GetBytes.

I'm not sure what a GitConverter does, but I'm sure it involves Gits. ;-)

Jay

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:OO**************@TK2MSFTNGP10.phx.gbl... Ken,

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)? Personally that is the key word "error prone"! .NET goes out of its way to
avoid such error prone code!

One of the drawbacks with VB6 and earlier was the difficulty in casting a 'record' to a different 'shape' so one could perform different

manipulations

on it.

Luckily VB6 & VB.NET have type safety! I consider this a major benefit not

a drawback!

Note a VB6 Type is a VB.NET Structure, however I would recommend using a
Class instead.

I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes so that I could perform a checksum
calculation on the contents. I would "serialize" the structure to a MemoryStream using a BinaryWriter.

I would then calculate the checksum on the MemoryStream. Both MemoryStream &
BinaryWriter are in the System.IO namespace. Alternatively you can use
System.GitConverter.GetBytes to get byte arrays for individual members
however the BinaryWriter & MemoryStream makes this significantly easier!

Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information. I would use an BinaryReader to read the header information interpreting &
"deserializing" as I go. BinaryReader is also in the System.IO namespace.

By "serialize" and "deserialize" I mean I would implement custom routines
that would convert an object to & from a binary format using the
BinaryReader & BinaryWriter classes similar to what is described in the
following article:

http://msdn.microsoft.com/library/de...rp09182003.asp
Note the samples are C#, with your C++ background you should be able to
convert them.

An alternative to the BinaryReader & BinaryWriter is the
System.Runtime.InteropSerivces.Marshal class. Check out the StructureToPtr & PtrToStructure methods along with the Copy or Read methods. Although the
method is StructureToPtr you can use them with either a VB.NET Class or a
Structure...

Hope this helps
Jay

"Ken Allen" <ke******@sympatico.ca> wrote in message
news:ee******************@tk2msftngp13.phx.gbl...

I am relatively new to .Net, but have been using VB and C/C++ for years.

One of the drawbacks with VB6 and earlier was the difficulty in casting a 'record' to a different 'shape' so one could perform different

manipulations

on it. For example, I have a complex data structure, which I can represent in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes so that I could perform a checksum
calculation on the contents. Another case is where a read a buffer from a file and then wish to interpret the contents based on some header
information. This was also very difficult in VB6.

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?

-Ken

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

Sorry, but when you assigned it 17i you already cast it.
No, it is only boxed.
So the types
are the same by the time it gets to direct cast.
The type of the reference using o is 'Object'. After DirectCast the type of
the reference is Integer.

If your statement were true both of the following statements would work.
Only the first does:
msgbox(directcast(o, integer).maxvalue)
msgbox(o.maxvalue)
However, I am a little confused over this, because after casting
occurs 'o' still maintains the Type 'Object' in the Locals window
although the Object pointed to is of Type Integer.

Can you adequately explain this to me ?

The IDE shows the *declared* type of o, and this is Object. In the value
column, the *instance* type is shown.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[One Handed Man [ OHM# ]]

What do you mean by boxed ?

Armin Zingler wrote:

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

Sorry, but when you assigned it 17i you already cast it.

No, it is only boxed.

So the types
are the same by the time it gets to direct cast.

The type of the reference using o is 'Object'. After DirectCast the
type of the reference is Integer.

If your statement were true both of the following statements would
work. Only the first does:
msgbox(directcast(o, integer).maxvalue)
msgbox(o.maxvalue)

However, I am a little confused over this, because after casting
occurs 'o' still maintains the Type 'Object' in the Locals window
although the Object pointed to is of Type Integer.

Can you adequately explain this to me ?

The IDE shows the *declared* type of o, and this is Object. In the
value column, the *instance* type is shown.

Regards - OHM# On**********@BTInternet.com

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

What do you mean by boxed ?

A variable declared As Object occupies 4 bytes. If you assign a value type
to the variable, the size of the object can not always be 4 bytes to fit
into the variable. Consequently the object is stored on the heap and the
reference to the object is stored in the variable. Just like reference
types.
Look for "boxed" in
http://msdn.microsoft.com/library/en...valuetypes.asp

See also KB article 311327:
http://support.microsoft.com/default.aspx?scid=kb;[LN];311327

and (look for "boxing"):
http://msdn.microsoft.com/library/en...tinternals.asp


Strange, I didn't find anything in the VB.Net docs.... :-(
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Rob Teixeira [MVP]]

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Oz**************@TK2MSFTNGP10.phx.gbl...

I'm not sure what a GitConverter does, but I'm sure it involves Gits. ;-)

Jay

Good movie :-)

Anyway, I agree completely about the Type safety thing. C++ allows far too
many nasty bugs and convoluted code due to treating memory as some arbitrary
blob of bits that can be read/manipulated any way you like.
However, the one upside to the C++ behavior is that you don't need a COPY of
the bits if you want to look at it differently. If you want to play
semi-nice and keep the copying to a minimum, you could pin the object, then
use the Marshal class to peek 1 byte (or 1 int, or 1 long, etc.) at a time
and calculate the checksum that way.

Getting back to the original post:

What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?
C# does indeed have pointers (check "unsafe" code), and VB can operate
similarly by using the Marshal class and pinned GC handles. However, both
languages are completely type-safe, so you cannot cast arbitrarily (which
really has more to do with the instance data itself rather than the pointer
that is pointing to it).
One of the drawbacks with VB6 and earlier was the difficulty in casting a
'record' to a different 'shape' so one could perform different manipulations on it.
In a type-safe OO system, you treat entities differently by using
polymorphism - which doesn't do EXACTLY the same thing under the hood, but
allows you to manipulate different entities with like interfaces in a
completely structured and type-safe manner.
For example, I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes
If you pin the structure, you can read the memory as if it were bytes with
the Marshal class.
Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information.

You can always use the binary serializer to serialize the entity to a byte
stream (and deserialize the byte stream back into the entity). Extremely
convenient, but it does add type information to the stream.

-Rob Teixeira [MVP]

[One Handed Man [ OHM# ]]

I understood that primitives are wrapped in a class, but I thought that this
was how they are allways used. Its unclear to me what situations a value
type is stored wrapped and when not.

The texts you recommended I read tell the developer to not "OverBox", but no
example did I see to clarify when this might occur.

Can you illuminate please ? - Thanks for your patience and help here. I had
thought I was clear on this but I am not.

Regards - OHM
Armin Zingler wrote:

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

What do you mean by boxed ?
A variable declared As Object occupies 4 bytes. If you assign a value
type to the variable, the size of the object can not always be 4
bytes to fit into the variable. Consequently the object is stored on
the heap and the reference to the object is stored in the variable.
Just like reference types.
Look for "boxed" in
http://msdn.microsoft.com/library/en...valuetypes.asp

See also KB article 311327:
http://support.microsoft.com/default.aspx?scid=kb;[LN];311327

and (look for "boxing"):

http://msdn.microsoft.com/library/en...tinternals.asp

Strange, I didn't find anything in the VB.Net docs.... :-(

Regards - OHM# On**********@BTInternet.com

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

I understood that primitives are wrapped in a class, but I thought
that this was how they are allways used.
How do you mean this? (if my explanation below is unclear)
Its unclear to me what
situations a value type is stored wrapped and when not.

The texts you recommended I read tell the developer to not "OverBox",
but no example did I see to clarify when this might occur.

Can you illuminate please ? - Thanks for your patience and help here.
I had thought I was clear on this but I am not.

The object is boxed whenever the object is assigned to a variable that also
accepts reference types. The only type (I know of) that fulfills this
precondition is System.Object.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[One Handed Man [ OHM# ]]

After these statement(s)

Dim o As Object
Dim i As Integer = 8
Dim ub as Integer

Then the following statments

o = 8

or

o = i

Result in a New 'Boxed' primitive on the heap with the value which was
assigned.

And 'Unboxing ' is the defererencing of 'o'

ub = o
Do I have this correct now ?

Regards - OHM

Armin Zingler wrote:

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

I understood that primitives are wrapped in a class, but I thought
that this was how they are allways used.

How do you mean this? (if my explanation below is unclear)

Its unclear to me what
situations a value type is stored wrapped and when not.

The texts you recommended I read tell the developer to not "OverBox",
but no example did I see to clarify when this might occur.

Can you illuminate please ? - Thanks for your patience and help here.
I had thought I was clear on this but I am not.

The object is boxed whenever the object is assigned to a variable
that also accepts reference types. The only type (I know of) that
fulfills this precondition is System.Object.

Regards - OHM# On**********@BTInternet.com

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

After these statement(s)

Dim o As Object
Dim i As Integer = 8
Dim ub as Integer

Then the following statments

o = 8

or

o = i

Result in a New 'Boxed' primitive on the heap with the value which
was assigned.
Right
And 'Unboxing ' is the defererencing of 'o'

ub = o
ub = directcast(o, integer)

Right, the integer value on the heap is copied to ub (and ub is on
the stack).
Do I have this correct now ?

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Cor]

In Holland and Dutch speaking Belgium they say

Heap Heap Hoera,

:-))

Cor

[One Handed Man [ OHM# ]]

OK, So now we have established that. I then put it to you that my original
statement is correct, which is that directCast only works with reference
types, because when they are Boxed, they become referenced. Your assertion
was that Boxed types also work, this is true.

BTW the assignment

ub = o
Works during compile and runtime. The casting is done implicitly it seems.

Thank you for your patience. I wont bother you further on this one as we
have done it to death.
Regards - OHM



Cor wrote: In Holland and Dutch speaking Belgium they say

Heap Heap Hoera,

:-))

Cor

Regards - OHM# On**********@BTInternet.com

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

OK, So now we have established that. I then put it to you that my
original statement is correct, which is that directCast only works
with reference types, because when they are Boxed, they become
referenced.
This is not completely right. You wrote:
"DirectCast can only be used on reference types"
A boxed integer is accessed using a reference to the heap, but an Integer
value is still not a reference type.

Your assertion was that Boxed types also work, this is
true.

BTW the assignment

ub = o
Works during compile and runtime. The casting is done implicitly it
seems.

Enable option strict.
Thank you for your patience. I wont bother you further on this one as
we have done it to death.

You didn't bother me! :-)

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Rob,

C# does indeed have pointers (check "unsafe" code), and VB can operate
similarly by using the Marshal class and pinned GC handles. I was going to mention unsafe code, however I was gearing my answer to only
VB6 & VB.NET. I have not really used pinned GC handles, I'll have to
remember that hack (err trick) ;-). Remember with great power comes great
responsibility, using unsafe code & pinned GC handles significantly
increases your responsibility!
You can always use the binary serializer to serialize the entity to a byte
stream (and deserialize the byte stream back into the entity). Extremely
convenient, but it does add type information to the stream. I did not mention the normal binary serializer directly as the OP wanted to
do a checksum, as you mention the type information will totally screw up the
checksum! ;-)

Thanks for the addition info.
In a type-safe OO system, you treat entities differently by using
polymorphism - which doesn't do EXACTLY the same thing under the hood, but
allows you to manipulate different entities with like interfaces in a
completely structured and type-safe manner. This was part of the intent of my post, although you can cast the pointer in
C++ (or even use unsafe C# code) and do some truly "evil" (cool, neat,
clever) things, that .NET is a whole new ball game. The OP should consider
learning the new ways of doing things rather then continuing to rely on the
old way of doing things. Yes there may be performance issues (coping the
structure to calculate the checksum). However! is copying the structure the
performance issues you need to worry about in your app? You know the rule
where you optimize the code that has proven (via profiling) performance
issues, not the code you think has performance issues!

Although I do like the idea of a pinned pointer to calculate the checksum,
especially where that calculation is 200% encapsulated in its own class! My
concern would be where the layout of the structure (due to padding) is
slightly different then the layout of the structure on "paper" and disk. For
example reference types in the structure.

Just a thought
Jay
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:uE**************@TK2MSFTNGP11.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Oz**************@TK2MSFTNGP10.phx.gbl...

I'm not sure what a GitConverter does, but I'm sure it involves Gits. ;-)

Jay
Good movie :-)

Anyway, I agree completely about the Type safety thing. C++ allows far too
many nasty bugs and convoluted code due to treating memory as some

arbitrary blob of bits that can be read/manipulated any way you like.
However, the one upside to the C++ behavior is that you don't need a COPY of the bits if you want to look at it differently. If you want to play
semi-nice and keep the copying to a minimum, you could pin the object, then use the Marshal class to peek 1 byte (or 1 int, or 1 long, etc.) at a time
and calculate the checksum that way.

Getting back to the original post:
What facilities are available in VB.Met and C# (which does not have
pointers, which made this so easy, albeit error prone, in C and C++)?
C# does indeed have pointers (check "unsafe" code), and VB can operate
similarly by using the Marshal class and pinned GC handles. However, both
languages are completely type-safe, so you cannot cast arbitrarily (which
really has more to do with the instance data itself rather than the pointer that is pointing to it).
One of the drawbacks with VB6 and earlier was the difficulty in casting a 'record' to a different 'shape' so one could perform different manipulations on it.
In a type-safe OO system, you treat entities differently by using
polymorphism - which doesn't do EXACTLY the same thing under the hood, but
allows you to manipulate different entities with like interfaces in a
completely structured and type-safe manner.
For example, I have a complex data structure, which I can represent
in a VB6 TYPE declaration, but I cannot easily convert that to a fixed
length array of unsigned bytes
If you pin the structure, you can read the memory as if it were bytes with
the Marshal class.
Another case is where a read a buffer from a
file and then wish to interpret the contents based on some header
information.

You can always use the binary serializer to serialize the entity to a byte
stream (and deserialize the byte stream back into the entity). Extremely
convenient, but it does add type information to the stream.

-Rob Teixeira [MVP]

[One Handed Man [ OHM# ]]

OK, one last thing.

A boxed integer is accessed using a reference to the heap, but an
Integer value is still not a reference type.
I know an integer is not a reference type, i didnt say it was. Maybe what I
should have said was that DirectCast cannot be given references to Value
Types ( Unboxed ) . As when they are boxed they become a class and to the
outside world become reference types in disguise.

QUOTES
For each value type, the runtime supplies a corresponding boxed type, which
is a 'class' that has the same state and behavior as the value type. Some
languages require you to use special syntax when the boxed type is required;
others automatically use the boxed type when it is needed. When you define a
value type, you are defining both the boxed and the unboxed type.
END QUOTES

BTW: I Cant beleive, I had option strict OFF, I turned it off to test
something the other day and forgot to switch it back on again :Grrrrrr ;-)

Regards - OHM
Armin Zingler wrote: "One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

OK, So now we have established that. I then put it to you that my
original statement is correct, which is that directCast only works
with reference types, because when they are Boxed, they become
referenced.

This is not completely right. You wrote:
"DirectCast can only be used on reference types"
A boxed integer is accessed using a reference to the heap, but an
Integer value is still not a reference type.

Your assertion was that Boxed types also work, this is
true.

BTW the assignment

ub = o

Works during compile and runtime. The casting is done implicitly it
seems.

Enable option strict.

Thank you for your patience. I wont bother you further on this one as
we have done it to death.

You didn't bother me! :-)

Regards - OHM# On**********@BTInternet.com

[Ot]

A lurker would like to say "Thank You!" to Armin. What a great set of
references!

"Armin Zingler" <az*******@freenet.de> wrote in message
news:u3**************@TK2MSFTNGP12.phx.gbl...

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

What do you mean by boxed ?
A variable declared As Object occupies 4 bytes. If you assign a value

type to the variable, the size of the object can not always be 4 bytes to fit
into the variable. Consequently the object is stored on the heap and the
reference to the object is stored in the variable. Just like reference
types.
Look for "boxed" in
http://msdn.microsoft.com/library/en...valuetypes.asp

See also KB article 311327:
http://support.microsoft.com/default.aspx?scid=kb;[LN];311327

and (look for "boxing"):
http://msdn.microsoft.com/library/en...tinternals.asp

Strange, I didn't find anything in the VB.Net docs.... :-(
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[One Handed Man [ OHM# ]]

yes but he still didnt answer the last question.

OHM
Ot wrote:

A lurker would like to say "Thank You!" to Armin. What a great set of
references!

"Armin Zingler" <az*******@freenet.de> wrote in message
news:u3**************@TK2MSFTNGP12.phx.gbl...

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

What do you mean by boxed ?

A variable declared As Object occupies 4 bytes. If you assign a
value type to the variable, the size of the object can not always be
4 bytes to fit into the variable. Consequently the object is stored
on the heap and the reference to the object is stored in the
variable. Just like reference types.
Look for "boxed" in
http://msdn.microsoft.com/library/en...valuetypes.asp

See also KB article 311327:
http://support.microsoft.com/default.aspx?scid=kb;[LN];311327

and (look for "boxing"):

http://msdn.microsoft.com/library/en...tinternals.asp

Strange, I didn't find anything in the VB.Net docs.... :-(
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

Regards - OHM# On**********@BTInternet.com

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

yes but he still didnt answer the last question.

Oooops.. I wrote some lines yesterday but forgot to send them. Later.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

"One Handed Man [ OHM# ]"
<OneHandedMan@&REMOVE&TO%MAIL%MEBTInternet.com> schrieb

OK, one last thing.

A boxed integer is accessed using a reference to the heap, but
an Integer value is still not a reference type.
I know an integer is not a reference type, i didnt say it was.

I think you did say it. You wrote:

my original statement is correct, which is that directCast only
works with reference types, because when they are Boxed, they
become referenced.

The decisive part is your statement that "..directcast only works with
reference types". As Directcast works with boxed Integers, you implicitly
say that an Integer is a reference types.

Maybe
what I should have said was that DirectCast cannot be given
references to Value Types ( Unboxed ) .
yes
As when they are boxed they
become a class and to the outside world become reference types in
disguise.

IMO: no. An object that is a value type, like a structure, can never become
a class.

Maybe you are looking for a not existing problem. :-)
Different example: You can pass a value type ByRef to a procedure. It will
also be accessed using the passed reference but the object is still not a
reference type.
--
Armin

[One Handed Man [ OHM# ]]

Armin wrote:

IMO: no. An object that is a value type, like a structure, can never
become a class.

OHm Writes:
The following quote is from Microsoft Itself.

QUOTES
For each value type, the runtime supplies a corresponding boxed type, which
<<<<<<<<<<<<<<< THIS LINE
is a 'class' that has the same state and behavior as the value type. Some
<<<<<<<<<<<<<<< AND THIS LINE
languages require you to use special syntax when the boxed type is required;
others automatically use the boxed type when it is needed. When you define a
value type, you are defining both the boxed and the unboxed type.
END QUOTES
OHM

[Armin Zingler]

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

Armin wrote:

IMO: no. An object that is a value type, like a structure, can
never become a class.

OHm Writes:
The following quote is from Microsoft Itself.

QUOTES
For each value type, the runtime supplies a corresponding boxed type,
which <<<<<<<<<<<<<<< THIS LINE
is a 'class' that has the same state and behavior as the value type.
Some <<<<<<<<<<<<<<< AND THIS LINE
languages require you to use special syntax when the boxed type is
required; others automatically use the boxed type when it is needed.
When you define a value type, you are defining both the boxed and the
unboxed type. END QUOTES

Interesting. I think it is not completely true. Example:

Dim o As Object

o = Me 'In Form1
DirectCast(o, Form1).Visible = True

o = New Point(0, 0)
DirectCast(o, Point).X = 7

Last line fails.

Well, saying "it is not completely true".... Say, after applying
Directcast, it is not handled as a boxed value type anymore, so the
statement can also be considered true. That's a matter of interpretation. In
the end, everything is data or code. ;-) A test comes into my mind:

test(DirectCast(o, Point))

Private Sub test(ByRef p As Point)

End Sub

Question: Which reference is passed to sub test? The reference to the heap,
or is the point copied to the stack and a reference to the copy on the stack
is passed? Result: the latter is the case. If it were handled as a reference
type, the former would apply.

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[One Handed Man [ OHM# ]]

Honest answer, I dont know !

Maybe you could start a new thread and ask, Jay to give his comment on this
, I find it both intruiging and perplexing. I dont like things I cant get to
the bottom of.

Regards - OHM
Armin Zingler wrote:

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

Armin wrote:

IMO: no. An object that is a value type, like a structure, can
never become a class.

OHm Writes:
The following quote is from Microsoft Itself.

QUOTES
For each value type, the runtime supplies a corresponding boxed type,
which <<<<<<<<<<<<<<< THIS LINE
is a 'class' that has the same state and behavior as the value type.
Some <<<<<<<<<<<<<<< AND THIS LINE
languages require you to use special syntax when the boxed type is
required; others automatically use the boxed type when it is needed.
When you define a value type, you are defining both the boxed and the
unboxed type. END QUOTES

Interesting. I think it is not completely true. Example:

Dim o As Object

o = Me 'In Form1
DirectCast(o, Form1).Visible = True

o = New Point(0, 0)
DirectCast(o, Point).X = 7

Last line fails.

Well, saying "it is not completely true".... Say, after applying
Directcast, it is not handled as a boxed value type anymore, so the
statement can also be considered true. That's a matter of
interpretation. In the end, everything is data or code. ;-) A test
comes into my mind:

test(DirectCast(o, Point))

Private Sub test(ByRef p As Point)

End Sub

Question: Which reference is passed to sub test? The reference to the
heap, or is the point copied to the stack and a reference to the copy
on the stack is passed? Result: the latter is the case. If it were
handled as a reference type, the former would apply.

Regards - OHM# OneHandedMan{at}BTInternet{dot}com

[Armin Zingler]

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

Honest answer, I dont know !
What are you referring to?
Maybe you could start a new thread and ask, Jay to give his comment
on this , I find it both intruiging and perplexing. I dont like
things I cant get to the bottom of.

Sorry, what does "intruiging" mean?
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Armin,

test(DirectCast(o, Point))

Private Sub test(ByRef p As Point)

End Sub

Question: Which reference is passed to sub test? The reference to the heap, or is the point copied to the stack and a reference to the copy on the stack is passed? Result: the latter is the case. If it were handled as a reference type, the former would apply. A reference to a copy on the stack is passed, as the DirectCast unboxed the
Point object. One way to see what is happening is to use ILDASM.EXE to see
what IL was created.
o = New Point(0, 0)
DirectCast(o, Point).X = 7 Remember when you box or unbox a value type a copy of the data is made! The
DirectCast does an unbox on the o variable. The assignment to o made a copy
of the value type when it boxed it, then the DirectCast made a second copy
when it unboxed the value type.

Which is where the error that VB.NET gives you is nice, as it prevents you
from having an extremely obscure bug in your application! ;-)

Box uses the "special class" that OHM referenced and copies the data to it,
while unbox copies the data from the "special class".

I'm not sure if the "Common Language Infrastructure Standard" will explain
it any better as it states it in a similar manner to OHM's quote. See
"\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool Developers
Guide\docs\Partition I Architecture.doc" if you have VS.NET 2003 installed,
for VS.NET 2002 it should be in a similar "2002" path.

I have not followed this thread closely, however I get the impression you
are both correct, you are just describing a different angle of the same
beast. ;-)

Hope this helps
Jay

"Armin Zingler" <az*******@freenet.de> wrote in message
news:uT**************@TK2MSFTNGP10.phx.gbl... "One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

Armin wrote:

IMO: no. An object that is a value type, like a structure, can
never become a class.

OHm Writes:
The following quote is from Microsoft Itself.

QUOTES
For each value type, the runtime supplies a corresponding boxed type,
which <<<<<<<<<<<<<<< THIS LINE
is a 'class' that has the same state and behavior as the value type.
Some <<<<<<<<<<<<<<< AND THIS LINE
languages require you to use special syntax when the boxed type is
required; others automatically use the boxed type when it is needed.
When you define a value type, you are defining both the boxed and the
unboxed type. END QUOTES

Interesting. I think it is not completely true. Example:

Dim o As Object

o = Me 'In Form1
DirectCast(o, Form1).Visible = True

o = New Point(0, 0)
DirectCast(o, Point).X = 7

Last line fails.

Well, saying "it is not completely true".... Say, after applying
Directcast, it is not handled as a boxed value type anymore, so the
statement can also be considered true. That's a matter of interpretation.

In the end, everything is data or code. ;-) A test comes into my mind:

test(DirectCast(o, Point))

Private Sub test(ByRef p As Point)

End Sub

Question: Which reference is passed to sub test? The reference to the heap, or is the point copied to the stack and a reference to the copy on the stack is passed? Result: the latter is the case. If it were handled as a reference type, the former would apply.

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Cor]

Hi Armin,

Intriguing, why OHM gets a "what does intruiging" means back, and I always
"I don't understand Sorry" and can I try to find what part you do not
understand the syntax or the meaning.

:-))

Cor

[One Handed Man [ OHM# ]]

What are you referring to? Well, saying "it is not completely true".... Say, after applying
Directcast, it is not handled as a boxed value type anymore, so the
statement can also be considered true. That's a matter of interpretation. In
the end, everything is data or code. A test comes into my mind:

test(DirectCast(o, Point))

Private Sub test(ByRef p As Point)

End Sub

Question: Which reference is passed to sub test? The reference to the heap,
or is the point copied to the stack and a reference to the copy on the stack
is passed? Result: the latter is the case. If it were handled as a reference
type, the former would apply.

To me this would be the former. Point is a reference Type and the object
passed to DirectCast must be of the same type at runtime.


Sorry, what does "intruiging" mean?

Very interesting, something which captivates ones attention.

Regards - OHM# OneHandedMan{at}BTInternet{dot}com

[Armin Zingler]

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb

Armin,

test(DirectCast(o, Point))

Private Sub test(ByRef p As Point)

End Sub

Question: Which reference is passed to sub test? The reference to
the heap,

or is the point copied to the stack and a reference to the copy on
the

stack

is passed? Result: the latter is the case. If it were handled as
a

reference

type, the former would apply.

A reference to a copy on the stack is passed, as the DirectCast
unboxed the Point object. One way to see what is happening is to use
ILDASM.EXE to see what IL was created.

o = New Point(0, 0)
DirectCast(o, Point).X = 7

Remember when you box or unbox a value type a copy of the data is
made! The DirectCast does an unbox on the o variable. The assignment
to o made a copy of the value type when it boxed it, then the
DirectCast made a second copy when it unboxed the value type.

Right. That's what I wrote in the text you quoted.

I have not followed this thread closely, however I get the impression
you are both correct, you are just describing a different angle of
the same beast. ;-)

ACK. That's why I wrote "That's a matter of interpretation". ;)
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[One Handed Man [ OHM# ]]

Jay,
Thanks for stepping in to what has become a very confusing thread
for me at least. I think I now understand what's going on between all the
conversations between myself and Armin and what you have written here.

It all started when I replied to the OP stating that DirectCast only works
with reference type. Armin replied this was not the case IE Boxed/Unboxed.
When I looked into this I concluded that although this was true, that they
were in effect refrence types because of the way the CLR handles them at
runtime.

This was the essence of the disagreement.

I think that MS should really clear this up. I realise that this is unlikely
to cause anyone a significant problem however, from an academic point of
view it would be nice for MS to clearly state how this all works under the
covers.
Regards - OHM

[Jay B. Harlow [MVP - Outlook]]

Armin,

ACK. That's why I wrote "That's a matter of interpretation". ;) I guess I would use perspective instead of interpretation.

Of course applying either "perspective" or "interpretation" is a matter of
interpretation also! ;-)

As we enter an endless recursive spiral of semantics ;-)

Jay

"Armin Zingler" <az*******@freenet.de> wrote in message
news:el**************@TK2MSFTNGP10.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb

Armin,

test(DirectCast(o, Point))

Private Sub test(ByRef p As Point)

End Sub

Question: Which reference is passed to sub test? The reference to
the

heap,

or is the point copied to the stack and a reference to the copy on
the

stack

is passed? Result: the latter is the case. If it were handled as
a

reference

type, the former would apply.

A reference to a copy on the stack is passed, as the DirectCast
unboxed the Point object. One way to see what is happening is to use
ILDASM.EXE to see what IL was created.

o = New Point(0, 0)
DirectCast(o, Point).X = 7

Remember when you box or unbox a value type a copy of the data is
made! The DirectCast does an unbox on the o variable. The assignment
to o made a copy of the value type when it boxed it, then the
DirectCast made a second copy when it unboxed the value type.

Right. That's what I wrote in the text you quoted.

I have not followed this thread closely, however I get the impression
you are both correct, you are just describing a different angle of
the same beast. ;-)

ACK. That's why I wrote "That's a matter of interpretation". ;)
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

I think that MS should really clear this up. I realise that this is
unlikely to cause anyone a significant problem however, from an
academic point of view it would be nice for MS to clearly state how
this all works under the covers.

What has to be clarified? There are reference types, there are value types,
and there are boxed value types. I don't find the problem.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

What are you referring to?

[...]

ok. I think Jay is right when saying we are talking about the same beast.

Sorry, what does "intruiging" mean?

Very interesting, something which captivates ones attention.

Thx. (not part of my dictionary and lycos translation also didn't translate
it).
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

"Cor" <no*@non.com> schrieb

Intriguing, why OHM gets a "what does intruiging" means back, and I
always "I don't understand Sorry" and can I try to find what part you
do not understand the syntax or the meaning.

:-))

???
Cor, I don't understand you (again).

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[One Handed Man [ OHM# ]]

Just when I thought it was safe to go into the kicthen . . . . .

In my mind, once it has become boxed. As far as the CLR is concerned, it
seems that it might be handled as a reference type in a special way.

I'm glad you dont find a problem with it, that means you can sleep easy at
night, us mere mortals sometimes find it difficult when our IQ's are less
than 240.

;-)
Maybe it's time to end the thread ?

Regards - OHM

Armin Zingler wrote:

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

I think that MS should really clear this up. I realise that this is
unlikely to cause anyone a significant problem however, from an
academic point of view it would be nice for MS to clearly state how
this all works under the covers.

What has to be clarified? There are reference types, there are value
types, and there are boxed value types. I don't find the problem.

Regards - OHM# OneHandedMan{at}BTInternet{dot}com

[Cor]

Hi Jay,

I followed this thread and did not understand well what it was all about.

Has it to do with the old problem that a reference to a value cost more
memory and processing than a copy of a value?

Cor

[Armin Zingler]

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

Maybe it's time to end the thread ?

For me, of course. *I* didn't have a problem. ;-))))
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Herfried K. Wagner [MVP]]

* "Armin Zingler" <az*******@freenet.de> scripsit:

Intriguing, why OHM gets a "what does intruiging" means back, and I
always "I don't understand Sorry" and can I try to find what part you
do not understand the syntax or the meaning.

:-))

???
Cor, I don't understand you (again).

Is it Cor or is it you who has the problem?

SCNR

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Armin Zingler]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schrieb

???
Cor, I don't understand you (again).

Is it Cor or is it you who has the problem?

SCNR

I could tell you if I knew the problem. ;)

EOT

--
Armin

[Jay B. Harlow [MVP - Outlook]]

Cor,

Has it to do with the old problem that a reference to a value cost more
memory and processing than a copy of a value? I'm not sure how you mean 'reference', do you mean reference parameters or
reference types?

You are correct using boxed value types will cost more memory & processing
time, as the values need to be boxed & unboxed (placed on the heap & removed
from the heap).

This thread is primarily about when a value type becomes a "reference type"
which occurs when you assign a value type to an object variable. Within the
CLR this is the box IL instruction. Its also about what's the best way to
refer to this "boxed value type". I use both "boxed value type" and
"reference type", as I consider a "boxed value type" is a "reference
type"...

Hope this helps
Jay

"Cor" <no*@non.com> wrote in message
news:O6**************@TK2MSFTNGP10.phx.gbl... Hi Jay,

I followed this thread and did not understand well what it was all about.

Has it to do with the old problem that a reference to a value cost more
memory and processing than a copy of a value?

Cor

[Jay B. Harlow [MVP - Outlook]]

OHM & Armin:

In my mind, once it has become boxed. As far as the CLR is concerned, it
seems that it might be handled as a reference type in a special way. Correct! Once a value type is boxed, it is treated as any other reference
type! (I'm sure there are one or two special rules, however I have not come
across them yet).

See "7.2.4 - Boxing and Unboxing of Values" in
"\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool Developers
Guide\docs\Partition I Architecture.doc" (or the respective SDK or VS.NET
2002 locations).

The CLR needs to box a value type any time that value type needs to be
"treated" as a Reference type, which includes (note there may be other
places that cause boxing to occur):
- Assigning a value type to an Object variable
- Assigning any enum to a System.Enum variable
- Assigning any value type to a System.ValueType variable
- Assigning a value type to any Interface variable
- Using overridable methods inherited from Object, that are not overridden
in a Structure (ToString for example)

The CLR needs to unbox a "boxed value type" then it assigns(casts) one of
above variables to a variable of the respective value type.

Remember that IL has special instructions (box & unbox), so the CLR itself
knows how to convert the value type on the stack into a reference type on
the heap (boxing) and converting a boxed value type on heap to a value type
on the stack (unboxing). VB.NET chose to support the IL box and unbox
instructions implicitly in some cases (boxing mostly) and via the CType &
DirectCast instructions (unboxing mostly, you can use CType to box). C# uses
a normal cast instruction. conceptually someone designing their own language
could introduce some distinctive keywords that represents boxing & unboxing,
however I am not aware of any that specifically have.

Most of the above is what you two have already stated, in one form or
another!

Of course I may have just tipped the canoe again, and every one is back in
the water ;-)

Hope this helps
Jay

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com> wrote in
message news:e2**************@TK2MSFTNGP09.phx.gbl... Just when I thought it was safe to go into the kicthen . . . . .

In my mind, once it has become boxed. As far as the CLR is concerned, it
seems that it might be handled as a reference type in a special way.

I'm glad you dont find a problem with it, that means you can sleep easy at
night, us mere mortals sometimes find it difficult when our IQ's are less
than 240.

;-)
Maybe it's time to end the thread ?

Regards - OHM

Armin Zingler wrote:

"One Handed Man [ OHM# ]" <OneHandedMan{at}BTInternet{dot}com>
schrieb

I think that MS should really clear this up. I realise that this is
unlikely to cause anyone a significant problem however, from an
academic point of view it would be nice for MS to clearly state how
this all works under the covers.

What has to be clarified? There are reference types, there are value
types, and there are boxed value types. I don't find the problem.

Regards - OHM# OneHandedMan{at}BTInternet{dot}com

[Armin Zingler]

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb

You 'tipped the canoe' ;-)

I use both "boxed value type" and
"reference type", as I consider a "boxed value type" is a
"reference type"...

It is not as my previous example showed. See another one:

Dim f1, f2 As Form1
Dim o1, o2 As Object

f1 = New Form1
f2 = f1
o1 = New Point(10, 20)
o2 = o1

'f2 = f1' copies the reference because a Form is a class and a class is a
reference type. If boxed value types are the same as reference types,
'o2 = o1' would also copy the reference - the reference to the object on the
heap. It doesn't. The object is copied => boxed value types are not
reference types.

Of course, at a lower level, both "types of types" are on the heap and there
is a reference to the objects in both cases. But: the term "reference type"
is not related to this low level. The term "reference type" is used at a
higher level at which we do distinguish between value types and reference
types. Further more, the type of the object stays the same when boxed,
doesn't it? The type is still System.Drawing.Point. System.Drawing.Point is
a value type, no matter if a certain Point object is boxed or not. The type
System.Drawing.Point is defined in the Framework, and I don't think the
Framework changes just because we execute a statement at run-time that boxes
an instance of the type.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Armin,

If boxed value types are the same as reference types,
'o2 = o1' would also copy the reference - the reference to the object on
the heap. It doesn't. From the point of view of the Framework (the CLR) "boxed value types" are
reference types. Period! The CLR documentation I gave states so. Period!

No amount of what you think you are seeing is going to change the fact that
"boxed value types" are "Reference types"! As you are seeing the "smoke and
mirrors" of VB.NET. ;-)

This is from the "Common Language Infrastructure" (CLI) which is the
definition of how the CLR itself works. (url previously given).

<quote>
7.2.4 Boxing and Unboxing of Values
For every Value Type, the CTS defines a corresponding Reference Type called
the boxed type. The reverse is not true: Reference Types do not in general
have a corresponding Value Type. The representation of a value of a boxed
type (a boxed value) is a location where a value of the Value Type may be
stored. A boxed type is an object type and a boxed value is an object.

All Value Types have an operation called box. Boxing a value of any Value
Type produces its boxed value, i.e. a value of the corresponding boxed type
containing a bit copy of the original value. All boxed types have an
operation called unbox. Unboxing results in a managed pointer to the bit
representation of the value.

Notice that interfaces and inheritance are defined only on Reference types.
Thus, while a Value Type definition (see clause
7.9.7_cor_Value_Type_Definitions) can specify both interfaces that shall be
implemented by the Value Type and the class (System.ValueType or
System.Enum) from which it inherits, these apply only to boxed values.
</quote>

types. Further more, the type of the object stays the same when boxed,
doesn't it? The type is still System.Drawing.Point. System.Drawing.Point is a value type, no matter if a certain Point object is boxed or not. The type System.Drawing.Point is defined in the Framework, and I don't think the
Framework changes just because we execute a statement at run-time that boxes an instance of the type. No, according to the "Common Language Infrastructure" a "boxed type" is
created, I suspect by the JIT, as I have not read that far into the CLI yet.

The way I think of this is the "boxed ValueType" type is a proxy for the
respective "ValueType" type, allowing the "boxed ValueType" to be a
reference type that exists on the heap, while the "ValueType" itself exists
on the stack. That both "boxed ValueType" & "ValueType" are treated
identical at the IL & higher level (in that you never actually see the
"boxed ValueType" type). My understanding is the "boxed ValueType" type is
at a level within the CLR itself (below the IL level).
Of course, at a lower level, both "types of types" are on the heap and there is a reference to the objects in both cases. Correct, that is why a "boxed value type" is a "reference type"!

< But: the term "reference type" is not related to this low level. The term "reference type" is used at a
higher level at which we do distinguish between value types and reference
types. Wrong: Reference Type & Value type is used at the lower level (IL, CLI)
also, just like we use them at the higher level, same meanings & rules!
If boxed value types are the same as reference types,
'o2 = o1' would also copy the reference - the reference to the object on
the heap. It doesn't. The problem you are seeing is that "o2 = o1" does not do a simple
assignment! The VB.NET assignment operator (for objects) actually calls the
System.Runtime.CompilerServices.RuntimeHelpers.Get ObjectValue(object) helper
function on the source (o1), the value returned is then assigned to your
destination (o2). This allows VB.NET to reinforce value semantics even with
"boxed value types". You can verify this using ILDASM.EXE.

According to MSDN: RuntimeHelpers.GetObjectValue: "Returns a boxed copy of
obj if it is a value class; otherwise obj itself is returned". Hence GetObje
ctValue
enforces value semantics.

Unfortunately due to the "extra code" (the GetObjectValue) injected by
VB.NET, I don't see a way to "show the code" to show you that a "boxed value
type" is a reference type. If you know C#, it does not call the
GetObjectValue...

I will agree with you that VB.NET makes "boxed value types" appear to be
something more special then they really are. In that GetObjectValue causes a
copy to be made. However! I hope you will agree that just because they
appear not to be a reference type, does not make them not a reference type!

Hope this helps
Jay
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Cor,

Has it to do with the old problem that a reference to a value cost more
memory and processing than a copy of a value? I'm not sure how you mean 'reference', do you mean reference parameters or
reference types?

You are correct using boxed value types will cost more memory & processing
time, as the values need to be boxed & unboxed (placed on the heap &

removed from the heap).

This thread is primarily about when a value type becomes a "reference type" which occurs when you assign a value type to an object variable. Within the CLR this is the box IL instruction. Its also about what's the best way to
refer to this "boxed value type". I use both "boxed value type" and
"reference type", as I consider a "boxed value type" is a "reference
type"...

Hope this helps
Jay

"Cor" <no*@non.com> wrote in message
news:O6**************@TK2MSFTNGP10.phx.gbl...

Hi Jay,

I followed this thread and did not understand well what it was all about.
Has it to do with the old problem that a reference to a value cost more
memory and processing than a copy of a value?

Cor

[Armin Zingler]

Jay,

this is actually the reply to your other message (11:43 your local time
(18:43 my local time *g*)), but I could not send it:

("Posting failed, Server result: 441 (629) Article Rejected -- Ill-formed
message id '<uf**************@tk2msftngp13.phx.gb' in field 'References:'")
Anyway, here it is:
I read it, I wrote something - but here is the short version of the answer:
;-)

You say that you don't know whether System.Drawing.Point is a reference type
or a value type?
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote