Casting?

[Shannon Richards]

Hello: I am confused about casting...

Option Strict = ON

Example1:
---------------
When I say something like this...

Dim lo_Foo = New Foo
Dim lo_Obj as Object = lo_Foo

Works Fine!


Example2:
---------------
When I say something like this...

Dim lo_Foo = New Foo

OutPutObj(lo_Foo)

Public Sub OutPutObj(ao_Obj as Object)
...
End Sub

Compile Error: "Option Strict ON disallows implicit conversion from
System.Object to type Foo"

Isn't there an implicit conversion in the first example when the variable of
type object is set to the instance of Foo???

Thank you,
Shannon Richards
BBA, AIT, MCP

 

[Herfried K. Wagner [MVP]]

Hello: I am confused about casting...

Option Strict = ON

Example1:
---------------
When I say something like this...

Dim lo_Foo = New Foo
Dim lo_Obj as Object = lo_Foo

Works Fine!


Example2:
---------------
When I say something like this...

Dim lo_Foo = New Foo

OutPutObj(lo_Foo)

Public Sub OutPutObj(ao_Obj as Object)
...
End Sub

Compile Error: "Option Strict ON disallows implicit conversion from
System.Object to type Foo"

Where does it say that? It doesn't say that for the code you posted.

The message will be shown when casting from a base type to one of its
derived type, but not when "casting" from the derived type to the base type.
That's why the cast to 'Object' will always work.

 

[Scott M.]

All types of sedan automobiles are cars, but not all cars are sedan
automobiles.

You can cast a sedan as a car, but you can't cast a car as a sedan.

Get it?

 

[Ken Dopierala Jr.]

Hi Shannon,

Option Strict On doesn't allow late-binding. For some reason I believe the
compiler considers your first example either early-binding or allowed
late-binding and your second example illegal late-binding with Option Strict
On. I think that is what is going on but I'm not totally positive. My
point is that maybe this isn't a casting problem but a binding problem.
Some research on binding could give you a definitive answer. Good luck!
Ken.

 

[Mike McIntyre]

Shannon,

What is IncomeGateway? A Collection or ArrayList, or? Is it strongly type to only contain Income objects?

Same question for List?


--
Mike

Mike McIntyre
Visual Basic MVP
www.getdotnetcode.com
Here's what's really happening:

lo_Gateway.Insert(ByRef ao_Object As Object) - takes an argument of type object.

Since all reference types derive from object in .Net why is the compiler giving this error? Income is an Object...

 

[Jay B. Harlow [MVP - Outlook]]

Shannon,
In addition to the other comments (especially Nick's):

Insert is using ByRef, Do you really need ByRef here? Probably not.

ByVal & ByRef Parameters are independent of Reference & Value Types. All
parameters in VB.NET by default are passed ByVal, you should only pass a
parameter ByRef when you have to, which is when you need to modify the
callers variable.

A Reference Type is an object that exists on the heap. If I have a variable
that is a reference type and assign the variable to another variable. Both
variables will be pointing to the same object on the heap.

Dim x As Person
x = New Person()
Dim y As Person
y = x

Both x & y are the exact same Person object on the heap.

A Value Type does not live on the Heap. If I have a value type variable and
I assign it to another variable, a copy of the value is made.

Dim x As Integer
x = 100
Dim y As Integer
y = x

Although both x & y have the value 100, they are physically different values
as a copy was made.

Now when you pass a variable to a ByVal parameter a copy of the variable is
made. So for a Reference Type a copy of the reference is made, which means
there is still only one object on the heap & two references to that object.
For a Value Type a copy of the value is made.

When you pass a variable to a ByRef parameter a reference to that variable
is made. So for a Reference Type you have a reference to a reference to the
object, for a Value Type you have a reference to the value.

Remember ByVal & ByRef are how parameters are passed. Reference & Value
Types are how quantities are stored.

The following site also does a good job of explaining Reference & Value
types & ByRef & ByVal parameters.

http://www.yoda.arachsys.com/csharp/parameters.html


Hope this helps
Jay



Here's what's really happening:

lo_Gateway.Insert(ByRef ao_Object As Object) - takes an argument of type
object.

Since all reference types derive from object in .Net why is the compiler
giving this error? Income is an Object...

 

[Shannon Richards]

Hello: Thank you all for your fantastic comments. I understand more about
the issue now.

One additional question...
When dealing with reference types as parameters. Is it more efficient to
code the parameter as ByRef since ByVal will end up creating another pointer
to the reference type being passed into the method?

Thank you,
Shannon

 

[Jay B. Harlow [MVP - Outlook]]

Shannon,
It is more correct to use ByVal, as ByVal indicates the intent of your code!

ByVal indicates that you do not intend on modifying the caller's variable.

ByRef indicates that you intend on modifying the caller's variable.


I would not worry about "more efficient" unless the routine was profiled &
proven to have a efficiency problem. (see 80/20 below)


I have not profiled the effect of ByVal verses ByRef, however I would expect
ByRef to be a fraction of a nanosecond slower, as you are dereferencing two
references (you dereference the parameter, then you dereference the
variable). Where as ByVal you do a single dereference (you dereference the
parameter). In both cases a value needs to be placed on the stack. Also the
compiler & JIT compiler can & will optimize the code, if I attempt to use
ByRef to "optimize" the code & second guess the optimizer, I may wind up
hurting the compiler's or JIT's optimizations...

So I use ByVal & ByRef to indicate intent of the code.


Just Remember the 80/20 rule. That is 80% of the execution time of your
program is spent in 20% of your code. I will optimize (worry about
performance, memory consumption) the 20% once that 20% has been identified &
proven to be a performance problem via profiling (CLR Profiler is one
profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

Info on the CLR Profiler:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto13.asp

http://msdn.microsoft.com/library/d...y/en-us/dndotnet/html/highperfmanagedapps.asp

Hope this helps
Jay

 

[Cor Ligthert]

Shanon,

One additional question...
When dealing with reference types as parameters. Is it more efficient to
code the parameter as ByRef since ByVal will end up creating another
pointer to the reference type being passed into the method?

In my idea it was just the oposite.

However see this message in this newsgroup

http://groups.google.com/[email protected]

Cor