Implicit Type Conversion

[JaedenRuiner]

As a matter of course, many languages handle a lot of type conversions on the fly, and I've noticed that sometimes (with multiple overloads of methods) the compiler doesn't catch the fact that there are too many arguments for a specific call to a function, so I turned on Option Strict to help find them all (as I was changing some parameter orders), and found quite a few "implicit type conversion" errors that are found under option strict.

Though I do not intend to keep Strict on, I was curious, as to the nature of the VB language, if it is better to use the Ctype() inline function in certain circumstance, or if it is truly a "6 in one half-dozen in the other".

Example:

dim st as string = iif(X=0, "No", "Yes")
  or
dim st as string = CType(iif(x=0, "no", "yes"), String)

Does it really make much difference? Is it better VB coding practice to use the Ctype in this circumstance, or not?
Thanks

 

[jmcilhinney]

Though I do not intend to keep Strict on

Um, very, very, VERY bad decision. You should ALWAYS have Option Strict turned On and ONLY turn it Off on those very rare occasions when it's required, and even then only at the file level and only in the files that specifically require it.

Having Option Strict On will detect a lot of instance where a run time error could occur. It still doesn't ensure that it won't but it draws your attention to the possibility and forces you to take some action. If you take the wrong action then the compiler can't really be held responsible for that.

It's quite possible to write code with Option Strict Off that will never throw a run time exception. It's easier to make a mistake though, because you don't have the compiler double-checking. Even if your code is perfect though, with Option Strict Off the final product will run slower because the compiler will add lots of extra type-checking code. That should be reason enough to have Option Strict On.

Finally, you shouldn't be using IIf in VB 2008 at all anyway. You should be using the new If operator. It can infer the return type from the parameters, so no cast is required. In other cases though, you should ABSOLUTELY always perform an explicit cast or conversion when a narrowing conversion must occur. Option Strict On enforces that, which is a good thing.

 

[JaedenRuiner]

Finally, you shouldn't be using IIf in VB 2008 at all anyway. You should be using the new If operator.

Didn't even know about it. One of those VB6 back lashes. Thanks for pointing it out, that is VERY helpful.

The primary reason i don't like the option strict is in the typeless reference passing. I'm so used to Pointer based languages (languages that don't have as much compiler type checking and leave the onus of that burden on the programmer) that many times i need to return a reference in a reference passed object, but the return will be "nothing" or Nil as it were in Pascal.

thus:

Sub Free(ByRef O as Object) 
  O = Nothing
  GC.Collect
end Sub

There are several times where the "garbage collector" isn't fast enough to remove certain references that pertain to open files or marshalled COM objects, and the only way to get rid of them is via a forced garbage collection. The above may cause a run-time error, but that is on me...not the compiler. It is specifically designed to "NULL" a referenced variable, but the option strict complains when I do this:

dim MyObj as New SomeOtherObject()
MyObj.DoSomething
Free(MyObj)

I Can't type cast the MyObj because VB doesn't type cast, it has "conversion functions" so the function result cannot be reference passed.
I will look into other ways to achieve this, unless of course there is a way to determine at run time if an object is a reference type, then I could do something like this:

<System.Runtime.CompilerServices.Extension()> _
public Sub Free(Of T)(byref item as T)
  item = nothing
  GC.Collect
end sub

But I think that might cause a glitch if I tried it with an integer.
it furthermore complains about the ByRef types with regards to Excel Automated classes, because the ByRef type is Object, but the passed type is String for a filename, and I can't disable the strict simply for a single object, i have to do it for the whole file.

Also, there is that pesky annoyance with Enumerated types. It seems perfectly capable of thinking of the type as an Integer in memory, but the compiler doesn't think so.

Enum TempEnum
  enumVal1
  enumVal2
  enumVal3
  enumVal4
end Enum

dim x as TempEnum = TempEnum.enumVal1

x += 1

Now that works, without a hitch, but option strict won't even let me use the += operator on an enum even though an enum is effectively an integer unless otherwise typed, and I even when forcibly typed on declaration the integer operations aren't. VB is too type specific for my tastes...but then again, I learned on Voids and Pointers in structured programming, and picked up OOP after... I prefer handling types myself because I type cast quite a bit in many languages, and have had to deal with the typed bounds of VB.
I should not have to do:

dim x as tempEnum

x = CType(Ctype(x, Integer) + 1, tempenum)

just to increment an integer aligned enumerated type. *Shrug*

The difference is I expect the run time errors and compensate for them. If option strict off causes the compiler to do extra type checking, slowing down the process, then that's bad. I expect to know my types and to my type checking myself.

I use the TypeOf operator constantly because I'm in charge of types...which allows me more freedom, that obviously VB doesn't want me to have (*chuckle*).

I play around with it...maybe some files I'll turn it off, and others I won't...*shrug*


end sub

I'll play around with it, see what I can work out.
Thanks