C++ Compilation failed passing arrays as parameters

[SMcNeill]

SUBs are basically commands like CLS, PRINT, and END.  They don’t require parentheses, and you just call them as they exist.

CLS
PRINT “Hello World”
END

FUNCTIONs, on the other hand, give return values and generally require the use of parentheses with parameters.  Think of commands like SIN, COS, and _PRINTWIDTH.

x = SIN(.2)
y = COS(.6)
w = _PRINTWIDTH(“Hello World”)


The glitch you’ve encountered is a long lasting one that simply hasn’t been hunted down and fixed yet, and the c++ compilation fail is from calling the sub with parentheses around an array element.

Let’s say we have a simple sub like this one:

SUB foo (array())
END SUB

Calling it with foo (x()) will give you the c++ failure.
Calling it as foo x(), and it all works fine.

The IDE doesn’t catch the issue as it’s not actually an invalid syntax — in fact, you might even want to use it from time to time to pass values by reference, to keep values from passing back from the sub.  (Though you can’t right now, due to the glitch in it.)

Someday, somebody might get around to sorting the issue out, but this is one of our long-standing bugs that’s proven rather hard to track down and sort out.  With no foreseeable ETA on a fix, it’s best to just make a mental note of it: Don’t call SUBs and use parentheses around arrays in the parameters.

[bplus]

Thank you all for the responses!

(I'm brand new to QB64 -- looking to exciting stuff to do, this is my very first pandemic. The QB64 forum is certainly a lot more alive than I thought it might be -- please nobody take this the wrong way, but you have to admit that we are kind of at one of the extremities of the internet out here! Not unlike the Earth itself, a small but interesting outpost on the edge of the galaxy -- anything to get away from Javascript, amiright?)

==

Re: try3 is declared entirely wrong and used incorrectly.
Re: try2 is used incorrectly.

Reggie says:
True, but in both cases QB64 "fell down" into the C++ error, so I added them to the sample program while attempting to isolate the compiler bug:

[1] My assumption was/is that any such errors should be picked-up by QB64 proper, and that any fall-through to the internal C++ compiler is probably a reportable bug, regardless of the code that caused it to happen.

[2] I noticed the "Compilation failed" posting a few hours before mine, but the c++ error is different so they might be separate issues?

[3] When I first saw the error, I thought, "Weird, it's QBasic 4.5 compatible, but there's a C++ guy in there trying to get out! (It was like watching the movie Aliens, quite frankly!)

==
Re: Also, don't call the sub like try1 (cloud()). Call it like try1 cloud()

Reggie says:
Okay...I see now, that's working much better...thanks!
But now I'm confused -- the example on QB64's "FUNCTION" page shows parentheses included in FUNCTION calls. Is it different for SUB calls? Or they are optional?
[Searching...this might be interesting...]

==
Re: When you don't put a type behind it then it expects a SINGLE type. Your array is declared as an INTEGER type.

Reggie says:
Okay...I think this probably explains the problem with the sample code itself...
I see here, from the QB64 documentation:

    When a variable has not been defined or has no type suffix, the value defaults to SINGLE.
    (http://qb64.org/wiki/INTEGER)

    Parameters passed after the procedure call must match the variable types in the SUB parameters in order.
    http://www.qb64.org/wiki/SUB

And so the problem (with my code) was a kind-of subtle combination of the above two conditions...

==
Reggis says:
And so just to confirm though, there is a relatively new or under-explored compiler bug involved here? (Fall-through to C++ error)


Thanks again for all the help!
Reg

Yeah when the compiler does not correct my typo's and misuse of tools, it bugs me too! ;-))

A sub is defined with () enclosing the parameters but when called the modern way, no () needed.

You can put parenthesis around an argument so that it is not changed when exiting a sub. Otherwise you change a variable of same type as in definition (SUB or Function), that variable will go out of the sub (or function) a changed variable. This is actually handy but can cause problems to unaware or neglectful. Best to copy it inside sub or function if you are even going to _Trim$() it, unless that is effect you are after.

To do old QB4.5 Call a sub, then you put parenthesis around your arguments. It's there to be compatible with the old way. Call = () like a function,  no Call = no () Not like a function.

[bplus]

Perhaps the confusion arises because when you use a sub you are "calling" it but there is a keyword CALL that has rules that involve () when using the CALL keyword. CALL is so old that we still refer to it as "calling it" even though we no longer use the CALL keyword nor the ().

https://www.qb64.org/wiki/CALL

Who wants to take the old option of typing more stuff to use a sub?

Just people running code from 80's. You can use line numbers too.

[bplus]

I though you could put () around argument, works here:

Code: QB64: [Select]

1. x% = 4
2. test x%
3. PRINT x%
4. ' x% is now 5
5. test (x%)
6. PRINT x% 'still 5?
7.  
8. SUB test (this AS INTEGER)
9.     IF this = 1 THEN
10.         PRINT DATE$
11.     ELSEIF this = 2 THEN
12.         PRINT TIME$
13.     ELSE
14.         this = this + 1
15.         PRINT this
16.     END IF
17. END SUB
18.  

Is it the arrays then?

[bplus]

Yes works for array items too!

Code: QB64: [Select]

1. REDIM x%(1 TO 20)
2. FOR i = 1 TO 20
3.     x%(i) = i
4. NEXT
5. PRINT x%(4)
6. test x%(4)
7. PRINT x%(4)
8. ' x%(4) is now 5?
9. test (x%(4))
10. PRINT x%(4) 'still 5?
11.  
12. SUB test (this AS INTEGER)
13.     IF this = 1 THEN
14.         PRINT DATE$
15.     ELSEIF this = 2 THEN
16.         PRINT TIME$
17.     ELSE
18.         this = this + 1
19.         PRINT this
20.     END IF
21. END SUB
22.  

[SMcNeill]

Yes works for array items too!

Code: QB64: [Select]

1. REDIM x%(1 TO 20)
2. FOR i = 1 TO 20
3.     x%(i) = i
4. NEXT
5. PRINT x%(4)
6. test x%(4)
7. PRINT x%(4)
8. ' x%(4) is now 5?
9. test (x%(4))
10. PRINT x%(4) 'still 5?
11.  
12. SUB test (this AS INTEGER)
13.     IF this = 1 THEN
14.         PRINT DATE$
15.     ELSEIF this = 2 THEN
16.         PRINT TIME$
17.     ELSE
18.         this = this + 1
19.         PRINT this
20.     END IF
21. END SUB
22.  

Doesn’t work for arrays as a parameter.

DIM x(0)
x(0) = 1
foo (x())

SUB foo (array())
    FOR I = 0 TO UBOUND(array)
       PRINT array(I)
    NEXT
END SUB

[bplus]

That has me wondering, it is probably expecting only one item when use () around an argument. Could you pass arrays back in QB4.5 days? I am pretty sure array items were OK to pass.