Casting in VB.Net and C#

[Jay B. Harlow [MVP - Outlook]]

Re: Re: Casting in VB.Net and C#

Cor,[color=blue]
> 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?[/color]
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" <non@non.com> wrote in message
news:O68BmkjxDH A.2396@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Re: Casting in VB.Net and C#

OHM & Armin:[color=blue]
> 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.[/color]
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\T ool Developers
Guide\docs\Part ition I Architecture.do c" (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.ValueTyp e 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{a t}BTInternet{do t}com> wrote in
message news:e2qn6jjxDH A.1484@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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:[color=green]
> > "One Handed Man [ OHM# ]" <OneHandedMan{a t}BTInternet{do t}com>
> > schrieb[color=darkred]
> >> 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.[/color]
> >
> > 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.[/color]
>
> Regards - OHM# OneHandedMan{at }BTInternet{dot }com
>
>[/color]

[Armin Zingler]

Re: Re: Casting in VB.Net and C#

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

You 'tipped the canoe' ;-)
[color=blue]
> I use both "boxed value type" and
> "reference type", as I consider a "boxed value type" is a
> "reference type"...[/color]


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]]

Re: Re: Casting in VB.Net and C#

Armin,[color=blue]
> 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.[/color]
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_Definitio ns) can specify both interfaces that shall be
implemented by the Value Type and the class (System.ValueTy pe or
System.Enum) from which it inherits, these apply only to boxed values.
</quote>

[color=blue]
> 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[/color]
is[color=blue]
> a value type, no matter if a certain Point object is boxed or not. The[/color]
type[color=blue]
> 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[/color]
boxes[color=blue]
> an instance of the type.[/color]
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).
[color=blue]
> Of course, at a lower level, both "types of types" are on the heap and[/color]
there[color=blue]
> is a reference to the objects in both cases.[/color]
Correct, that is why a "boxed value type" is a "reference type"!

< But: the term "reference type"[color=blue]
> 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.[/color]
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!
[color=blue]
> 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.[/color]
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. CompilerService s.RuntimeHelper s.GetObjectValu e(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]" <Jay_Harlow_MVP @msn.com> wrote in message
news:%23XGGrBpx DHA.2396@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> Cor,[color=green]
> > 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?[/color]
> 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 &[/color]
removed[color=blue]
> from the heap).
>
> This thread is primarily about when a value type becomes a "reference[/color]
type"[color=blue]
> which occurs when you assign a value type to an object variable. Within[/color]
the[color=blue]
> 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" <non@non.com> wrote in message
> news:O68BmkjxDH A.2396@TK2MSFTN GP10.phx.gbl...[color=green]
> > Hi Jay,
> >
> > I followed this thread and did not understand well what it was all[/color][/color]
about.[color=blue][color=green]
> >
> > 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
> >
> >[/color]
>
>[/color]

[Armin Zingler]

Re: Re: Casting in VB.Net and C#

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 '<ufsalDyxDHA.3 116@tk2msftngp1 3.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

[Jay B. Harlow [MVP - Outlook]]

Re: Re: Casting in VB.Net and C#

Armin,[color=blue]
> You say that you don't know whether System.Drawing. Point is a reference[/color]
type[color=blue]
> or a value type?[/color]
No, I did not say that.

What I said was that System.Drawing. Point is a value type, that under the
covers the CLR also has a System.Drawing. Point 'reference type' that it uses
when you box a System.Drawing. Point value.

As a "boxed value type" is a "reference type".
[color=blue]
> ("Posting failed, Server result: 441 (629) Article Rejected -- Ill-formed
> message id '<ufsalDyxDHA.3 116@tk2msftngp1 3.phx.gb' in field[/color]
'References:'")
I understand that this is caused by the "References " field in the header to
be too long. I attempted to correct the references.

Hope this helps
Jay


"Armin Zingler" <az.nospam@free net.de> wrote in message
news:u%23%23HTC zxDHA.2440@TK2M SFTNGP12.phx.gb l...[color=blue]
> 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 '<ufsalDyxDHA.3 116@tk2msftngp1 3.phx.gb' in field[/color]
'References:'")[color=blue]
>
>
> Anyway, here it is:
>
>
> I read it, I wrote something - but here is the short version of the[/color]
answer:[color=blue]
> ;-)
>
> You say that you don't know whether System.Drawing. Point is a reference[/color]
type[color=blue]
> or a value type?
>
>
> --
> Armin
>
> http://www.plig.net/nnq/nquote.html
> http://www.netmeister.org/news/learn2quote
>[/color]

[Armin Zingler]

Re: Re: Casting in VB.Net and C#

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb[color=blue]
> Armin,[color=green]
> > You say that you don't know whether System.Drawing. Point is a
> > reference[/color]
> type[color=green]
> > or a value type?[/color]
> No, I did not say that.[/color]

By saying it depends on whether a point *object* is boxed or not, you
implicitly say that it does not depend on the *type* itself but on the
*instance*. In other words: According to the type you can not say whether
the type is a reference type or a value type.
[color=blue]
> What I said was that System.Drawing. Point is a value type, that under
> the covers the CLR also has a System.Drawing. Point 'reference type'
> that it uses when you box a System.Drawing. Point value.[/color]

dim o as object = new point (0,0)
msgbox o.gettype.fulln ame

=> Still "System.Drawing .Point"

Hmm....

;-)

--
Armin

[Jay B. Harlow [MVP - Outlook]]

Re: Re: Casting in VB.Net and C#

Armin,
Forgive my bluntness: Are you intentionally trying to turn things around or
do you truly not get what I am trying to explain?
[color=blue]
> By saying it depends on whether a point *object* is boxed or not, you
> implicitly say that it does not depend on the *type* itself but on the
> *instance*. In other words: According to the type you can not say whether
> the type is a reference type or a value type.[/color]
There are clearly documented ways on how to tell if a type is a reference
type or a value type. Which I know you understand.

Just as its documented when a value type can "also be" a reference type.
Which I get the impression eludes you, and my explanations are not helping
:-(
[color=blue]
> Hmm....
>
> ;-)[/color]
I get the impression you are simply trying to turn things around, without no
real desire to fully understand what I am tying to explain to you.

So I will conclude that this discussion has passed its useful life span...

Jay


"Armin Zingler" <az.nospam@free net.de> wrote in message
news:uCWA6$zxDH A.2720@TK2MSFTN GP09.phx.gbl...[color=blue]
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb[color=green]
> > Armin,[color=darkred]
> > > You say that you don't know whether System.Drawing. Point is a
> > > reference[/color]
> > type[color=darkred]
> > > or a value type?[/color]
> > No, I did not say that.[/color]
>
> By saying it depends on whether a point *object* is boxed or not, you
> implicitly say that it does not depend on the *type* itself but on the
> *instance*. In other words: According to the type you can not say whether
> the type is a reference type or a value type.
>[color=green]
> > What I said was that System.Drawing. Point is a value type, that under
> > the covers the CLR also has a System.Drawing. Point 'reference type'
> > that it uses when you box a System.Drawing. Point value.[/color]
>
> dim o as object = new point (0,0)
> msgbox o.gettype.fulln ame
>
> => Still "System.Drawing .Point"
>
> Hmm....
>
> ;-)
>
> --
> Armin
>[/color]

[Armin Zingler]

Re: Re: Casting in VB.Net and C#

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb[color=blue]
> Armin,
> Forgive my bluntness: Are you intentionally trying to turn things
> around or do you truly not get what I am trying to explain?[/color]

I could ask you the same. Please stay objective and don't get personal or
provocative.
[color=blue][color=green]
> > By saying it depends on whether a point *object* is boxed or not,
> > you implicitly say that it does not depend on the *type* itself but
> > on the *instance*. In other words: According to the type you can
> > not say whether the type is a reference type or a value type.[/color]
> There are clearly documented ways on how to tell if a type is a
> reference type or a value type. Which I know you understand.[/color]


There are clear proofes that back up my statements, but obviously you are
ingoring all of them. I would not have a problem to confess if I was wrong.
Please don't get me wrong, I just want to help you and make it easier for
you to agree with me even if it seems this is a one-way. I am really not
resentful.
[color=blue]
> Just as its documented when a value type can "also be" a reference
> type. Which I get the impression eludes you, and my explanations are
> not helping :-([/color]

Sorry, but you still didn't get the point. I'll try to ask again:

1. Do you consider System.Drawing. Point to be a value type or a reference
type? You ignored this question.


2. You also ignored:

<quote>
dim o as object = new point (0,0)
msgbox o.gettype.fulln ame

=> Still "System.Drawing .Point"
</quote>

Could you please tell me the full qualified name of a boxed
System.Drawing. Point object?


3. One more proof (refering to "...clearly documented ways on how to tell if
a type is a reference type or a value type"):

dim o as object = new point(0,0)
if typeof o is valuetype then
msgbox "valuetype"
end if

Despite the point object is boxed, the msgbox shows. Conclusion: a boxed
point object is a valuetype. BTW, the object is *not* unboxed before type
comparison takes place. If this still does not convince you I won't find
more words.


--
Armin

http://www.plig.net/nnq/nquote.html

http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Re: Re: Casting in VB.Net and C#

Armin,[color=blue]
> 1. Do you consider System.Drawing. Point to be a value type or a reference
> type? You ignored this question.[/color]
System.Drawing. Point is a value type, as it inherits from System.ValueTyp e!
When System.Drawing. Point is boxed it is also a reference type, as defined
by the CLI.
[color=blue]
> Could you please tell me the full qualified name of a boxed
> System.Drawing. Point object?[/color]
System.Drawing. Point

Yes, the value type itself & the "boxed value type" both have the exact same
type name! In fact both will return the exact same System.Type object when
you use the Object.GetType method. The CLR itself is hiding the fact there
is a boxed type is involved. If you need specifics on this hiding you will
need to read the Common Language Infrastructure specification, previously
quoted and referenced.
[color=blue]
> 3. One more proof (refering to "...clearly documented ways on how to tell[/color]
if[color=blue]
> a type is a reference type or a value type"):
> dim o as object = new point(0,0)
> if typeof o is valuetype then[/color]
I would expect "typeof o is valuetype" to be true as System.Drawing. Point is
a value type (as it inherits from System.ValueTyp e). Remember that
System.ValueTyp e itself is actually a Reference Type, based on CLI reference
I gave earlier (and the MSDN topic on System.ValueTyp e).

This is where IMHO you are missing the point, and I am having a HELL of a
time explaining it to you! I actually thought you had it earlier... Point is
a value type, when it is boxed it is a reference type. This is defined by
the CLR itself. The "type" of the box itself (as defined by GetType &
TypeOf) is the value type, so comparing the type of the boxed value is going
to be the value type itself. The CLR does this to simplify your code. If the
CLR did not do this, you would need to know what the name of a boxed Point
was, which means the 'boxed value type' type would need to be known at
compile time. Reading the passage I gave earlier from the CLI, I get the
impression the boxed value type's type is not created until runtime, this
makes sense to me as its not needed until runtime. The designers of the CLR
decided to make every ones lives easier by having the boxed value type
return the same type as the value type itself. For example, I only need to
know Point in the code below, I don't need to know what the 'boxed Point'
type is.

If TypeOf o Is Point Then
Dim pt As Point = DirectCast(o, Point)
End If
[color=blue]
> There are clear proofes that back up my statements, but obviously you are
> ingoring all of them. I would not have a problem to confess if I was[/color]
wrong.
I have not (knowingly) ignored any of your "proofs" I made a sincere effort
to demostrate where each of your "proofs" are not really proving anything. I
get the impression I did not do a very good job, hence my frustration with
myself. Both the CLR & VB.NET are going out of their way to make a boxed
value type appear to be a normal value type. Hence your "proofs", show you
exactly what you are expecting. When I look at your proofs, I see exactly
what you think you are seeing. Reading the CLI and looking at the IL I
understand why you think they are proofing, what you think they are
proofing, however I look a little deeper, yes as a child I disassembled most
of my toys. Looking at the underlying IL I see how VB.NET is hiding the
reference type from you with the GetObjectValue call. Also reading the CLI
specification I see how the CLR makes a reference type for the value type
under the covers and maps this two types to the same type to simplify our
code. Hence there is no need for ValueType & "Boxed ValueType" types in our
source! Such as those found in Java. For example: Java's int is a value
type, while its Integer is a class in the Java class library that represents
a boxed int. By making "boxed value types" reference types, the .NET
designers avoid requiring .NET developers needing to define the equivalent
Java's Integer class, as the CLR takes care of it for you, transparently!

Hope this helps
Jay

"Armin Zingler" <az.nospam@free net.de> wrote in message
news:%23kYKRD1x DHA.2620@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb[color=green]
> > Armin,
> > Forgive my bluntness: Are you intentionally trying to turn things
> > around or do you truly not get what I am trying to explain?[/color]
>
> I could ask you the same. Please stay objective and don't get personal or
> provocative.
>[color=green][color=darkred]
> > > By saying it depends on whether a point *object* is boxed or not,
> > > you implicitly say that it does not depend on the *type* itself but
> > > on the *instance*. In other words: According to the type you can
> > > not say whether the type is a reference type or a value type.[/color]
> > There are clearly documented ways on how to tell if a type is a
> > reference type or a value type. Which I know you understand.[/color]
>
>
> There are clear proofes that back up my statements, but obviously you are
> ingoring all of them. I would not have a problem to confess if I was[/color]
wrong.[color=blue]
> Please don't get me wrong, I just want to help you and make it easier for
> you to agree with me even if it seems this is a one-way. I am really not
> resentful.
>[color=green]
> > Just as its documented when a value type can "also be" a reference
> > type. Which I get the impression eludes you, and my explanations are
> > not helping :-([/color]
>
> Sorry, but you still didn't get the point. I'll try to ask again:
>
> 1. Do you consider System.Drawing. Point to be a value type or a reference
> type? You ignored this question.
>
>
> 2. You also ignored:
>
> <quote>
> dim o as object = new point (0,0)
> msgbox o.gettype.fulln ame
>
> => Still "System.Drawing .Point"
> </quote>
>
> Could you please tell me the full qualified name of a boxed
> System.Drawing. Point object?
>
>
> 3. One more proof (refering to "...clearly documented ways on how to tell[/color]
if[color=blue]
> a type is a reference type or a value type"):
>
> dim o as object = new point(0,0)
> if typeof o is valuetype then
> msgbox "valuetype"
> end if
>
> Despite the point object is boxed, the msgbox shows. Conclusion: a boxed
> point object is a valuetype. BTW, the object is *not* unboxed before type
> comparison takes place. If this still does not convince you I won't find
> more words.
>
>
> --
> Armin
>
> http://www.plig.net/nnq/nquote.html
> http://www.netmeister.org/news/learn2quote.html
>[/color]

[Armin Zingler]

Re: Re: Casting in VB.Net and C#

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb[color=blue]
> Armin,[color=green]
> > 1. Do you consider System.Drawing. Point to be a value type or a
> > reference type? You ignored this question.[/color]
> System.Drawing. Point is a value type, as it inherits from
> System.ValueTyp e! When System.Drawing. Point is boxed it is also a
> reference type, as defined by the CLI.
>[color=green]
> > Could you please tell me the full qualified name of a boxed
> > System.Drawing. Point object?[/color]
> System.Drawing. Point
>
> Yes, the value type itself & the "boxed value type" both have the
> exact same type name! In fact both will return the exact same
> System.Type object when you use the Object.GetType method. The CLR
> itself is hiding the fact there is a boxed type is involved. If you
> need specifics on this hiding you will need to read the Common
> Language Infrastructure specification, previously quoted and
> referenced.
> [...I-also-read-the-rest-only-did-not-quote-it...][/color]

I did not read the whole CLS so far. ;-) I don't wanna get megalomaniac ;)
but is it possible that the CLS documentation may "throw everything in one
pot" (=lumps everything together) concerning this specific point? Maybe
instead of writing "boxed value types are handled equally to reference
types" they write "boxed value types are reference types"? That's what I am
really not completely sure about it. Maybe I'll get into this level one day.
I'm not fit to discuss about it, yet.

My doubts come from the fact that in the managed world there *must* be
metadata that describes all types, but now suddenly there are "on the fly"
types that are not defined anywhere. That's where the contradiction comes
from IMO.

I can not imagine that we always strictly distinguish between reference
types and value types at a "high" level, e.g. when talking about it in this
group, whereas it is actually a CLI level issue. Therefore I thought (and,
sorry, I still think (probably *because* I'm not a low-level guy yet)) the
terms are not related to the CLI level. In addition, as you/the CLS says
that all value types are reference types because System.ValueTyp e is a class
(I did know this), I do not understand why we always say that a type is
_either_ a reference type _or_ a value type. Following your explanations,
any type is a reference type (because System.Valuetyp e is a class), but not
any reference type is also a value type. That's completely new to me, and
that's where and why we still disagree.

So let's say: EOT (the last time...). I'm really interested in which
insights will happen to me the next months. *g* I did not want to say that I
am absolutely right, I just wanted to put my statements opposite to yours to
find out the core that reveal the cause for our different points of view.


--
Armin

http://www.plig.net/nnq/nquote.html

http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

Re: Re: Casting in VB.Net and C#

"Armin Zingler" <az.nospam@free net.de> schrieb[color=blue]
> find out the core that reveal the cause for our different points of view.[/color]

What??

....find out the cause for our different points of view.


--
Armin

[jerry]

Re: Re: Casting in VB.Net and C#


Your posts are the _only_ reason I even open this newsgroup. And I am sure
this is true of others. Please do not let these people get to you. Please
just drop their antagonistic threads. Have you not noticed how many people
cease to post in this group forever because of Armin and Herfried
snottiness. They seem determined to lord this newsgroup and will turn on
any other person who dares to post regularly. I, for one, do not want to
see you go. So, please, drop it, move on, do not respond to their posts.

From a lurker who is really, really sick of this newsgroup.

[Jay B. Harlow [MVP - Outlook]]

Re: Re: Casting in VB.Net and C#

Armin,[color=blue]
> but is it possible that the CLS documentation may "throw everything in one
> pot" (=lumps everything together) concerning this specific point?[/color]
Possible, but I don't think that is the reason. However I'm not sure either
way.
[color=blue]
> Maybe
> instead of writing "boxed value types are handled equally to reference
> types" they write "boxed value types are reference types"?[/color]
Unfortunately depending on your point of view that quickly decades into
subtle semantic issues.

They wrote "boxed value types are reference types", I understand the why
they are reference types, I am willing to live with it.
[color=blue]
> My doubts come from the fact that in the managed world there *must* be
> metadata that describes all types, but now suddenly there are "on the fly"
> types that are not defined anywhere. That's where the contradiction comes
> from IMO.[/color]
I can see where that would cause confusion, unfortunately it may get worst
when we start learning how the meta data for Generics in Whidbey is stored,
based on my understanding on what I have read so far.

Hope this helps
Jay

"Armin Zingler" <az.nospam@free net.de> wrote in message
news:%23WO5ay7x DHA.1680@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb[color=green]
> > Armin,[color=darkred]
> > > 1. Do you consider System.Drawing. Point to be a value type or a
> > > reference type? You ignored this question.[/color]
> > System.Drawing. Point is a value type, as it inherits from
> > System.ValueTyp e! When System.Drawing. Point is boxed it is also a
> > reference type, as defined by the CLI.
> >[color=darkred]
> > > Could you please tell me the full qualified name of a boxed
> > > System.Drawing. Point object?[/color]
> > System.Drawing. Point
> >
> > Yes, the value type itself & the "boxed value type" both have the
> > exact same type name! In fact both will return the exact same
> > System.Type object when you use the Object.GetType method. The CLR
> > itself is hiding the fact there is a boxed type is involved. If you
> > need specifics on this hiding you will need to read the Common
> > Language Infrastructure specification, previously quoted and
> > referenced.
> > [...I-also-read-the-rest-only-did-not-quote-it...][/color]
>
> I did not read the whole CLS so far. ;-) I don't wanna get megalomaniac ;)
> but is it possible that the CLS documentation may "throw everything in one
> pot" (=lumps everything together) concerning this specific point? Maybe
> instead of writing "boxed value types are handled equally to reference
> types" they write "boxed value types are reference types"? That's what I[/color]
am[color=blue]
> really not completely sure about it. Maybe I'll get into this level one[/color]
day.[color=blue]
> I'm not fit to discuss about it, yet.
>
> My doubts come from the fact that in the managed world there *must* be
> metadata that describes all types, but now suddenly there are "on the fly"
> types that are not defined anywhere. That's where the contradiction comes
> from IMO.
>
> I can not imagine that we always strictly distinguish between reference
> types and value types at a "high" level, e.g. when talking about it in[/color]
this[color=blue]
> group, whereas it is actually a CLI level issue. Therefore I thought (and,
> sorry, I still think (probably *because* I'm not a low-level guy yet)) the
> terms are not related to the CLI level. In addition, as you/the CLS says
> that all value types are reference types because System.ValueTyp e is a[/color]
class[color=blue]
> (I did know this), I do not understand why we always say that a type is
> _either_ a reference type _or_ a value type. Following your explanations,
> any type is a reference type (because System.Valuetyp e is a class), but[/color]
not[color=blue]
> any reference type is also a value type. That's completely new to me, and
> that's where and why we still disagree.
>
> So let's say: EOT (the last time...). I'm really interested in which
> insights will happen to me the next months. *g* I did not want to say that[/color]
I[color=blue]
> am absolutely right, I just wanted to put my statements opposite to yours[/color]
to[color=blue]
> find out the core that reveal the cause for our different points of view.
>
>
> --
> Armin
>
> http://www.plig.net/nnq/nquote.html
> http://www.netmeister.org/news/learn2quote.html
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Re: Casting in VB.Net and C#

Jerry,
Thank you for the support!

I do not really view Armin as antagonistic. Although we all (me included)
have our antagonistic days.

I find both Armin & Herfried to be very good contributors to this newsgroup!
I even learn new things from them on occasion. (although I may not
necessarily acknowledge on each instance).

Don't worry I'm not going anywhere any time soon. As I've stated in other
posts, I find the newsgroups a good place to learn more myself. As when I
decide to answer difficult subtle questions, such as the discussion Armin &
I are having in this thread, it makes me think more and research more.
Hopefully both Armin & I walk out of this discussion with a better
understanding of how & why of the framework...

Thanks again for the words
Jay

"jerry" <jerry@nospam.c om> wrote in message
news:MPG.1a4f88 65c23c349d9896f c@msnews.micros oft.com...[color=blue]
>
> Your posts are the _only_ reason I even open this newsgroup. And I am sure
> this is true of others. Please do not let these people get to you. Please
> just drop their antagonistic threads. Have you not noticed how many people
> cease to post in this group forever because of Armin and Herfried
> snottiness. They seem determined to lord this newsgroup and will turn on
> any other person who dares to post regularly. I, for one, do not want to
> see you go. So, please, drop it, move on, do not respond to their posts.
>
> From a lurker who is really, really sick of this newsgroup.[/color]