[RESOLVED] option strict on

[pacerier]

should i put option strict on for a module which i intend to include in my projects? i meant the module itself not the projects.

because with it on, i had to convert strings to number before i can compare them, and i'm guessing that this conversion gives us unneccessary overhead

on a side note, the included module will be tested such that there would be no bugs, hence i was wondering if the option strict on for included modules is encouraged or discouraged

[Hack]

Option Strict On should be project wide for every project you do.

If you hadn't converted the strings prior to compiling, you would have had to when you tried to make an .exe

[ckennedy79]

I would go with strict on and using the type conversion functions like you mentioned. Depending on where the data comes from, you may want to check that each type of data is convertible to an integer before the conversion happens as well, if it's integer like numbers you are trying to compare.

How many times would this get called? Also, just because you don't foresee a user giving it a bad value, they will, and they will frequently.

[NickThissen]

Option Strict On is always encouraged except in a few rare cases where it is impossible to use (late-binding for instance). A module is no exception.

You don't have to convert strings to a number before comparing them. You can just compare strings? Or did you mean comparing like <, >, etc? In that case, you MUST convert the strings to numbers first, as these operators are not defined for strings. With Option Strict Off however, this conversion is done implicitly (you don't see it). So you are still not comparing strings, and the conversion to a number is still made, even though you didn't tell the compiler to do it. So no, there is no unnecessary overhead. In fact, I am pretty sure that it's the other way around: converting strings to integers implicitly is slower than explicitly, because the compiler would first need to realize that you do indeed want a number, and not the string, and only then can the conversion take place.

[pacerier]

well its something like i want to compare a string with a number so i have to call toString for the number with option strict on. is it the case that explicitly calling .toString will make things faster? because i thought that if i didn't vb will use their own way of comparing string to integer which is much faster compared to me changing the integer to string and comparing it with my string.


Re: How many times would this get called? Also, just because you don't foresee a user giving it a bad value, they will, and they will frequently.

well there's not a problem with user giving a bad value because the user is the programmer himself. i have no idea how many times it would be called because its a Procedure that can be included into my other Projects, or other people can include this Procedure in their projects.

i would say if i were to distribute it then the speed of execution would be important, even if i could reduce it by a few ticks i would, as long as the procedure does exactly what it is meant to

[NickThissen]

VB doesn't compare an integer with a string. It converts the integer to a string, and then compares two strings.

For example:

If "3" = 3 Then
 ...

I think the steps VB takes to execute this are more or less like:
- Compare "3" with 3
- String cannot be compared to integer
- Convert integer to string
- Compare "3" with "3".

Whereas if you do this:

If "3" = CStr(3) Then

It is probably more like this:
- Compare "3" with "3".

[Shaggy Hiker]

Option Strict ON is significantly faster. Normally, you won't see this, because few programs are so processor intensive that the advantage is noticeable. However, in a program I wrote that took several days of constant calculation, Option Strict caused about a 30-50&#37; improvement in speed. Yeah, you type a bit more, but the compiler generates more efficient code because of that.

There is a second reason for Option Strict, though, which is harder to explain. When you allow implicit conversions, you are relying on the compiler to get it right. That doesn't always happen, and leads to bugs. The only example I can think of off the top of my head is really trivial, but I have seen it happen on this forum:

MySumInALable.Text = (FirstIntegerInTextbox.Text + SecondIntegerInTextbox.Text)

Since + will add numbers or concatenate strings, this will not add the two integers, but concatenate the two strings.

[pacerier]

ok i will do it explicitly then. however after i've put strict on and checked that everything is "Strict" can i remove the line "option strict on" or is leaving it there important for the processor to execute faster?

[NickThissen]

The line Option Strict On only tells the compiler that it should check for implicit conversions, nothing else. In other words, yes, if you turn Option Strict Off after you are done writing everything, then the result will be the same as if you have left the line there.

However, I can't think of a single reason why you would want to do that. And I can think of many why you don't want to do that. So just don't.

[pacerier]

well i'm thinking if there's no reason for it to be there den i'll take it off, since the statement jus gives overhead and nothing else

[NickThissen]

Why would it give overhead? It is just a way to tell the compiler whether to allow implicit conversions or not. After compilation, you won't find it anywhere else. It is only relevant during compilation.

Note that you can also turn it on in the project properties. And you can make it the default option in the IDE options. That will allow you to use Option Strict without having the line Option Strict On in every document.

[pacerier]

oic, so execution time remains unaffected?
if dat's the case i will leave it there

[NickThissen]

Even if it did, it would take probably nanoseconds of your execution time.
If you are this concerned about your applications performance then I suggest you find another language (probably a low-level language like C), because VB is not meant for that kind of speed.

[Shaggy Hiker]

The line only impacts what the compiler flags as an error, it has no direct impact on the code itself. The indirect impact is that, since it changes what code you are allowed to write, then the code will be changed because you wrote explicit conversions in place of implicit ones. However, the line doesn't show up in the output file.

It sounds like you might be interested in looking at the IL generated by the code you type. By doing that, you can see EXACTLY what impact certain constructs have. However, I find that this is only useful for comparing just a few lines. Comparing entire functions can be very hard to understand, as IL is something like uncommented ASM, which is notoriously difficult to read. Still, if you are interested in seeing the IL, then look for ILDASM.exe, which should be located somewhere in the tree of directories that holds VS.

[pacerier]

cool, what exactly is the IL? or what does IL stands for so i can google it

[NickThissen]

The VB code is compiled into the MSIL (Microsoft Intermediate Language) (although I think it's now known as CIL, Common Intermediate Language?), which is a language that's independent of CPU/Platform and runs on the .NET framework. I believe the .NET framework will then compile the MSIL into code that the computer can read (bytecode) during run-time.

So the IL shows you exactly what your application does, without all the stuff that VB, or any other .NET language for that matter, offers to make programming easier for you.

[jmcilhinney]

I believe the .NET framework will then compile the MSIL into code that the computer can read (bytecode) during run-time.

Byte code is the Java equivalent of IL. Both MSIL and Java byte code are compiled Just-In-Time by their respective runtime environments into machine code, which is binary code a processor can execute.

[pacerier]

cool , i'll try to read more abt it tq