Why does this compile?

Hello, If I have

----------------------------

Public Sub Test(i As Integer)

End Sub

Load()

Test("Hello")

End Sub

-----------------


Why does the program compile with no errors? Shouldnt vb see that the argument passed to Test is not an integer?

Thanks

clearly the code as you posted it will not compile as you have two end subs with only one sub start. Post your actual code.

My question is, why does the code compile.
Shouldn't the compiler see that you are passing a
string as a parameter instead of an integer.


Public Sub Test(i As Integer)

End Sub

Private Sub Form_Load()

Test("Hello")

End Sub

That applies only when you pass a variable (i.e. a variable of type string)... You are passing a pointer to a local stack and VB renders the value into an integer ...

Hi,

I changed



Test("Hello") To

Dim t As String
t = "Hello"

Test(t)


It still compiles.

I don't think the compiler cares what you are passing a function. All it cares about is IF you are passing one or not and whether or not it requires one.

This is also true in your code.
Try a numeric variable that your are trying to use as alpha and create a calculation with it but don't run it to get a runtime error. Instead, just compile it and you'll see what I mean.

HTH

Hi,

I see that it doesnt care what type the argument is. I want to know if this is something that can be changed by choosing some sort of option in VB.

For example, what is the point of having types in the arguments of a function if they are not used to help the coder avoid passing incorrect things to functions before it is run.

Can someone give answer this.

You have option explicit turned on?

You have to remember how a function works.
Until you run it and pass it something then how is it going to know that what you are passing is valid or not? It's just code waiting for an action. There is no cross-referencing on arguments passed because on compile, you're not passing anything to it.

I have to ask this though: Why are you compiling something you haven't tested to begin with?

I have option exlicit.

I come from a c++ background.

The reason you want this to happen confus is because it makes more reliable and less buggy code.

What if I had the following code.

------------------

Public Enum Colour
Red = 1
Blue = 2
End Enum

Public Sub Test(col As Colour)


End Sub

Public Sub Form_Load()

Test(4)

End Sub

---------------

The compiler should see that 4 is not of type, Colour and it
should not compile. It makes the debugging easier.

My simple question is, does anyone know if vb can do this type of checking.






-----------------

There's a price to pay for ease of programming when using VB and you just found one of many in comparison to C++

Interpretive languages like VB, REXX, etc. have many flaws in comparison with more rigid languages like C++

C++ is not as forgiving as VB. It's hard to crash a user's PC with VB code unless you really screwed up badly. No so with C++

Not to mention the learning curb:D

I wonder then what is the point of using enums in the
arguments of a function

Quote:

---

Originally posted by duh
My simple question is, does anyone know if vb can do this type of checking.

The reason you want this to happen confus is because it makes more reliable and less buggy code.

---

Confucius is right, VB can test this. Run the program? It would make no sense to write a program, then not test it in the IDE and expect to have no bugs...

Ooops i jumped the gun, didn't see your last replys...

Oops!
Mine works :)
I mean it doesnt compile on my computer

Hi guys,

First of all, I have to agree with Duh on his comment:

Quote:

---

what is the point of having types in the arguments of a function if they are not used to help the coder avoid passing incorrect things to functions before it is run

---

VB does compile the example Duh posted when you would think it obviously shouldnt, but there are reasons why it does compile.

VB 4.0 introduces the concept of "automatic type coercion". Apparently it makes code more efficient, but what it means is that variables of certain data types can automatically get converted to other types without you having to convert it explicitly. Integers to Booleans, Strings to Dates, Strings to Numbers, etc. There are rules that get followed by VB with these coercions.

Obviously this isnt going to be everyones preferred coding approach, but its built into the fabric of VB and thus needs to be maintained for eternity to allow backward compatibility.

Anyway, the fact of the matter is that assigning a string to a integer is considered "legal" by the compiler due to these coercion rules, i.e., the string "1234" can be coerced to the number 1234, but the string "abcd" cannot, so its not until the code is actually executed that it realises that the text "abcd" is not really a number, and it then becomes a runtime error and not a compiler error. So compiling your code into an executable is allowed, but when you run it, you get a type mismatch runtime error.

Make sense?

Its not very strong type casting, and I am not sure if I agree with the whole idea of it myself ... you have CStr() CInt() CLng() etc, if you want to convert your data types, and I dont like VB making assumptions for me ... but for others it probably makes life alot easier.

So there you have it ... you are all smarter now :D

Cheers,
Tinbum747

mine did give an error. I run all my programs using the START WITH FULL COMPILE option on. Maybe thats the difference, if it is off then it onlys picks up the error after the line has been encountered.

Start with full compile, should pick-up those typo's or errors...

I am a c/c++ programmer myself, and c/c++ compiles the .cpp/.h files each time you run the application (depending on your environment settings), therefor c/c++ will pick this up, but in vb, it only runs the app no, error checking...

Explicitly pressing ctrl+F5 will force VB to compile the code to native-code which at this point should pickup stuff like that ... :)

But Option Explicit, needs to be turned on, and the keywords ->
'Option Explicit', needs to be at the top of each .frm, .mdl or what ever file .... :)

Sometimes, this option is off, an then in turn, when putting this on, it does not insert the key word at the top....

:)

Hi again,

Choosing 'Start With Full Compile' (Ctrl+F5) will still only check against compilation errors, not runtime errors.

If you take the following example:

Code:

---

Option Explicit

Public Sub Test(i As Integer)

End Sub

Private Sub Form_Load()
 
  Test "hello"

End Sub

---

When you run this example, you get a type mismatch error when you run the code, but it is a runtime error (it asks you if you want to debug or end, because your code is now running).

Now try the following, add a button to the form, and move the function call to the button click event:

Code:

---

Option Explicit

Public Sub Test(i As Integer)

End Sub

Private Sub Command1_Click()
 
  Test "hello"

End Sub

---

Choose 'Start With Full Compile' (Ctrl+F5) ... the form loads OK. Click on the button and you get the type mismatch runtime error.

Also, if you choose the 'Make xxx.exe' option from the File menu to compile your code into an executable, it works without errors.

Sadly you cant rely on using the 'Start With Full Compile' option to trap all of these runtime type mismatch errors, due to those coercion rules.

Cheers,
Tinbum747