simple SUB-procedure doesn't work

[MrFreyer]

Hi all,

anybody knows why this subprocedure doesn't work?

Code: QB64: [Select]

1. CLS
2.  
3. DIM SHARED var1 AS INTEGER
4. DIM SHARED var2 AS INTEGER
5. DIM SHARED var3 AS INTEGER
6. DIM SHARED sum1 AS INTEGER
7.  
8. DIM SHARED subvar1 AS INTEGER
9. DIM SHARED subvar2 AS INTEGER
10. DIM SHARED subvar3 AS INTEGER
11. DIM SHARED subsum1 AS INTEGER
12.  
13. var1 = 1
14. var2 = 2
15. var3 = 3
16.  
17. sum1 = 0
18.  
19. PRINT "var1:"; var1; " =1"
20. PRINT "var2:"; var2; " =2"
21. PRINT "var3:"; var3; " =3"
22. PRINT "sum1:"; sum1; " =0"
23. PRINT ""
24.  
25. CALL calc(var1, var2, var3, sum1)
26.  
27. PRINT "var1:"; var1; " =1"
28. PRINT "var2:"; var2; " =2"
29. PRINT "var3:"; var3; " =3"
30. PRINT "sum1:"; sum1; " =6 ?"
31.  
32. END
33.  
34. SUB calc (subvar1, subvar2, subvar3, subsum1)
35. subsum1 = subvar1 + subvar2 + subvar3
36. END SUB
37.  

I have written much more complex subprocedures, and (it seems like) they worked.

Thanks

[bplus]

Code: QB64: [Select]

1. CLS
2. DEFINT A-Z   '<<<<<<<<<<<<<<<< added this
3. DIM SHARED var1 AS INTEGER
4. DIM SHARED var2 AS INTEGER
5. DIM SHARED var3 AS INTEGER
6. DIM SHARED sum1 AS INTEGER
7.  
8. DIM SHARED subvar1 AS INTEGER
9. DIM SHARED subvar2 AS INTEGER
10. DIM SHARED subvar3 AS INTEGER
11. DIM SHARED subsum1 AS INTEGER
12.  
13. var1 = 1
14. var2 = 2
15. var3 = 3
16.  
17. sum1 = 0
18.  
19. PRINT "var1:"; var1; " =1"
20. PRINT "var2:"; var2; " =2"
21. PRINT "var3:"; var3; " =3"
22. PRINT "sum1:"; sum1; " =0"
23. PRINT ""
24.  
25. calc var1, var2, var3, sum1 '<<<< removed call and ()
26. PRINT
27. PRINT "Outside sub now in Main:"
28. PRINT "var1:"; var1; " =1"
29. PRINT "var2:"; var2; " =2"
30. PRINT "var3:"; var3; " =3"
31. PRINT "sum1:"; sum1; " =6 ?"
32.  
33. PRINT
34. PRINT "subvar1:"; subvar1; " =1"
35. PRINT "subvar2:"; subvar2; " =2"
36. PRINT "subvar3:"; subvar3; " =3"
37. PRINT "subsum1:"; subsum1; " =6 ?"
38.  
39.  
40.  
41. END
42.  
43. SUB calc (subvar1, subvar2, subvar3, subsum1)
44.     PRINT
45.     PRINT "Inside calc now recieved:"
46.     PRINT "subvar1:"; subvar1; " =1"
47.     PRINT "subvar2:"; subvar2; " =2"
48.     PRINT "subvar3:"; subvar3; " =3"
49.     PRINT "subsum1:"; subsum1; " =6 ?"
50.  
51.     subsum1 = subvar1 + subvar2 + subvar3
52.     PRINT
53.     PRINT "Inside calc now calced:"
54.     PRINT "subvar1:"; subvar1; " =1"
55.     PRINT "subvar2:"; subvar2; " =2"
56.     PRINT "subvar3:"; subvar3; " =3"
57.     PRINT "subsum1:"; subsum1; " =6 ?"
58.  
59. END SUB
60.  
61.  
62.  

But now it does work with CALL and () as well?!?! curious indeed!

[FellippeHeitor]

@MrFreyer:

You can only change a parameter if it matches types. In your case subsum1 is an INTEGER, but when you create the SUB, subsum1 is a SINGLE precision parameter.

The solution would be:

Code: QB64: [Select]

1. SUB calc (subvar1, subvar2, subvar3, subsum1 AS INTEGER)

If you want to use the variable you had already DIM SHARED before, don't create a new variable with the same name for a parameter:

Code: QB64: [Select]

1. SUB calc

After all, if all your variables are already SHARED, you don't need to pass them to the SUB anyway.

Now, it seems like what you actually want is a function. A function is a SUB too, but it returns a value:

Code: QB64: [Select]

1. FUNCTION calc(value1, value2, value3)
2.     calc = value1 + value2 + value3
3. END FUNCTION

This way you invoke it like this:

Code: QB64: [Select]

1. result = calc(subvar1, subvar2, subvar3)
2. 'or even
3. result = calc(1, 2, 3)

[MrFreyer]

Okay, now I get it.

Yes, I could do this as a function, but I was testing something other and just posted this selected piece of code.

Thanks!

[bplus]

OK he gets it...  but now I am confused.

subsum1 was dimensioned as an integer!

and code does work with DEFINT A-Z



Not that I would actually do this crazy stuff in code, I can find my own just fine!

[MrFreyer]

The SUB calc redimensioned the subsum1 as SINGLE (for the use in the subprocedure).
But if you use DEFINT A-Z, the subsum1 will automatically redimensioned as a INTEGER .

The variables subvar1, subvar2 and subvar3 will also redimensined as SINGLE, but they don't need to be shared with the maincode.
And that's the problem. subsum1 will be shared with the maincode, but a SINGLE (subsum1) and a INTEGER (sum1) dosn't fit together.

Am I right?

[FellippeHeitor]

Scope is the question here. When you DIM SHARED subvar1 AS INTEGER, you make it available globally. If you create any sub or function, you can access subvar1 from there, change it, erase it, redimension it (if it's an array). However, if you instruct QB64 that a SUB/FUNCTION needs to have a parameter that's also named subvar1, QB64 will assume that for this new scope you want a subvar1 that's not an INTEGER (remember that not defining a type makes a variable of type SINGLE). The local subvar1 parameter takes precedence over the shared variable. They are separate entities.

Internally (in the C++ output) you'll have __INTEGER_SUBVAR1 and _SUB_CALC_SINGLE_SUBVAR1, which can be verified by looking in internal/temp/main.txt.

[Pete]

A long time ago in an IDE far far away, we used COMMON SHARED instead of DIM SHARED.

Pete :)

[Edster]

I have a similar question so I thought I would tack it to the end of this thread.

DIM reply(i) AS STRING
CALL Answer(reply())
.
.
.
SUB Answer(passedReply() AS STRING)
    PRINT passedReply(i)
END SUB

The above code works just fine ...

DIM reply(i) AS STRING
PRINT Answer(reply())
.
.
.
FUNCTION Answer(passedReply() AS STRING)
    Answer = passedReply(i)
END FUNCTION

This code produces IILEGAL STRING-NUMBER CONVERSION error

However, if 'DEFSTR A' is used, then the above function works fine. The function name needs to be defined as string.

Should FUNCTIONS and SUBS differ in this way? It took me some time to figure out why the FUNCTION wouldn't work.

[FellippeHeitor]

Now that could be a bug. Give us some time to look into to it.

Edit:
No, not a bug. You're trying to return a string but your function is of type SINGLE. Fix it like this:

Code: QB64: [Select]

1. FUNCTION Answer$(passedReply() AS STRING)
2.     Answer$ = passedReply(i)
3. END FUNCTION

[Petr]

Try using DIM SHARED

[Edster]

Now that could be a bug. Give us some time to look into to it.

Edit:
No, not a bug. You're trying to return a string but your function is of type SINGLE. Fix it like this:

Code: QB64: [Select]

1. FUNCTION Answer$(passedReply() AS STRING)
2.     Answer$ = passedReply(i)
3. END FUNCTION

My bad, if I taken a closer look on wiki then I'd have seen the need for a type suffix for functions.

Thanks for pointing that out to me.

[FellippeHeitor]

My pleasure. Welcome to the forum!