Posts: 1,272
Threads: 119
Joined: Apr 2022
Reputation:
100
I had a tutorial user contact me about using the SHARED statement. He was trying to share variables in a subroutine like this:
SHARED a, b, c AS INTEGER
According to the Wiki this is not an alternate method of using SHARED, however, the IDE accepts this form and there is no run-time error either.
Code: (Select All) DIM AS INTEGER a, b, c
a = 10
b = 20
c = 30
Mysub
SUB Mysub ()
'---------------
' ** Method 1 ** ------------> ** THIS WORKS **
'---------------
'SHARED AS INTEGER a, b, c ' all SHARED on a single line
'---------------
' ** Method 2 ** ------------> ** THIS WORKS **
'---------------
'SHARED a AS INTEGER ' all SHARED on a separate line
'SHARED b AS INTEGER
'SHARED c AS INTEGER
'---------------
' ** Method 3 ** ------------> ** THIS WORKS **
'---------------
'SHARED AS INTEGER a, b ' two different SHARED alternatives
'SHARED c AS INTEGER
'---------------
' ** Method 4 ** ------------> ** THIS DOES -NOT- WORK **
'---------------
'SHARED a, b, c AS INTEGER ' only the value of 'c' is passed, 'a' and 'b' are zero.
'-----------------------------------------------------------------------------------
' Method 4 is not a valid alternative to SHARED listed in the Wiki and should
' therefore not work. However, I would think an error would be generated in the IDE
' or at least at run-time when SHARED is attempted to be used in this manner?
'-----------------------------------------------------------------------------------
PRINT a, b, c
END SUB
Shouldn't method 4 above get flagged somehow as being incorrect?
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 3,962
Threads: 175
Joined: Apr 2022
Reputation:
219
03-14-2023, 08:01 PM
(This post was last modified: 03-14-2023, 08:07 PM by bplus.)
I did not think Shared could be used in Subroutines but it appears so...
Anyway the 4th method makes sense to me because a, b are default single as "Shared" in the 4th Method of Sub
Quote:SHARED a, b, c AS INTEGER ' only the value of 'c' is passed, 'a' and 'b' are zero.
Here is a further mod to show what I see:
Code: (Select All) Dim As Integer a, b, c
a = 10
b = 20
c = 30
Mysub
Print a, b, c
Sub Mysub ()
'---------------
' ** Method 1 ** ------------> ** THIS WORKS **
'---------------
'SHARED AS INTEGER a, b, c ' all SHARED on a single line
'---------------
' ** Method 2 ** ------------> ** THIS WORKS **
'---------------
'SHARED a AS INTEGER ' all SHARED on a separate line
'SHARED b AS INTEGER
'SHARED c AS INTEGER
'---------------
' ** Method 3 ** ------------> ** THIS WORKS **
'---------------
'SHARED AS INTEGER a, b ' two different SHARED alternatives
'SHARED c AS INTEGER
'---------------
' ** Method 4 ** ------------> ** THIS DOES -NOT- WORK **
'---------------
Shared a, b, c As Integer ' only the value of 'c' is passed, 'a' and 'b' are zero.
'-----------------------------------------------------------------------------------
' Method 4 is not a valid alternative to SHARED listed in the Wiki and should
' therefore not work. However, I would think an error would be generated in the IDE
' or at least at run-time when SHARED is attempted to be used in this manner?
'-----------------------------------------------------------------------------------
a = 1.111: b = 2.222
Print a, b, c
End Sub
b = b + ...
Posts: 209
Threads: 13
Joined: Apr 2022
Reputation:
52
Another reason why I always use type suffixes, there's no worries about the correct syntax
Code: (Select All) SHARED a%, b%, c% 'all done, less typing, no ambiguities
However, as far as I remember, this syntax was one of Fellippes last improvements, at least for DIM (SHARED) blabla AS... but obviously it works for a simple SHARED as well. Unfortunatly Fellippe left the stage before he properly documented his additions/improvements.
Posts: 1,002
Threads: 50
Joined: May 2022
Reputation:
27
(03-14-2023, 10:38 PM)RhoSigma Wrote: Another reason why I always use type suffixes, there's no worries about the correct syntax
Code: (Select All) SHARED a%, b%, c% 'all done, less typing, no ambiguities
However, as far as I remember, this syntax was one of Fellippes last improvements, at least for DIM (SHARED) blabla AS... but obviously it works for a simple SHARED as well. Unfortunatly Fellippe left the stage before he properly documented his additions/improvements.
"Dim Shared . . ." only applies to the main program. "Shared" can only be used in Sub and Functions (QuickBasic Manual).
Today I don't feel like doing a test anymore. But I can assure you it works.
Main program: Dim Shared. . .
Posts: 2,696
Threads: 327
Joined: Apr 2022
Reputation:
217
SHARED a, b, c AS INTEGER
The above is valid, but you're mixing data types. a and b are undefined so they're SINGLE types. c is the only integer type above.
Add this to the main code:
a! = 1
b! = 2
Posts: 1,272
Threads: 119
Joined: Apr 2022
Reputation:
100
03-15-2023, 03:18 AM
(This post was last modified: 03-15-2023, 03:20 AM by TerryRitchie.)
(03-15-2023, 01:43 AM)SMcNeill Wrote: SHARED a, b, c AS INTEGER
The above is valid, but you're mixing data types. a and b are undefined so they're SINGLE types. c is the only integer type above.
Add this to the main code:
a! = 1
b! = 2
Ah, so it should be done as:
SHARED a AS INTEGER, b AS INTEGER, c AS INTEGER
Yeah, this makes sense.
Update: yep, just tried it, works. I'll pass this information along.
Thanks for sleuthing this out guys.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 1,586
Threads: 59
Joined: Jul 2022
Reputation:
52
We're going to get more of these from people who think BASIC is like Pascal. Or from a few programmers who programmed a lot in Pascal and think it's entirely sensible to translate directly:
[code]Var a, b, c : Integer;[code]
"If it works at the front, then it should work at the back too!" Because they didn't use QB64 while Galleon was the chief. Back then, at least while I had v0.98 every single variable had to be decorated with type specifically or it was at the mercy of a global first-letter-of-the-name definition. Even then still had to do it for UDT. Started calling for a type sigil for _MEM, LOL. The "DIM AS <type> ..." saved typing for a lot of people for sure, but it also made them think that they could turn the "AS <type>" to the end which got them into trouble.
I admit that this got me until I read SMcNeill's post.
Posts: 2,696
Threads: 327
Joined: Apr 2022
Reputation:
217
People need to learn to accept that *ALL* variables in QB64 are defined. By default, every variable is defined with a very basic: (DIM variable AS _DEFAULT_TYPE)
x = 3 .... now, what TYPE of variable is X? Since there's no user-explicit definition, there's the implied (DIM x AS _DEFAULT_TYPE). Without any DEF statement or _DEFINE statement in effect, then x is SINGLE.
Now, let's say we do something such as: DIM x, y AS INTEGER, z, alpha AS _FLOAT, beta AS DOUBLE
What variable types are each of those variables?
x is... we didn't specify, so it's _DEFAULT_TYPE.
y, we declared to be an INTEGER, so it's an INTEGER.
z is... once more, undeclared so it's _DEFAULT_TYPE
alpha is declared to be a _FLOAT
beta is declared to be a DOUBLE
The ONLY shortcut one might use to declare x and y both as INTEGERS at the same time would be:
DIM AS INTEGER x, y
DIM AS _FLOAT z, alpha
DIM AS DOUBLE beta
^A completely different syntax, with only one variable type being allowed per line, and that type has to be declared before any of the variable names. Makes for a great shorthand, but it's definitely not the same as placing the variable name before the type declaration.
And that's basically the whole issue for why Example 4 wasn't working the way the user was thinking it should. Two very similar ways to declare variables, but with vastly different results for each of the specific syntax uses.
Posts: 344
Threads: 24
Joined: Jul 2022
Reputation:
20
Hi
I can add that as for type of variable QB has others definition for default...
see SCREEN mode... it is for default SCREEN 0: WIDTH 80, 25:COLOR 7,0: LOCATE 1,1
run this code if you want to verify
Code: (Select All) Print "Hi QB64!"
_Delay 2
Cls
Screen 0
Width 80, 25
Color 7, 0
Locate 1, 1
Print "Hi QB64!"
so, coming back to variable type definition, if you do not use suffix or AS TYPE definition for each variables it will be the DEFAULT TYPE
that in QB/QB64 is single (!) variable type.
Code: (Select All) Dim a, b, c 'AS DEFAULT TYPE
Dim d! ' AS SINGLE TYPE
a = 1.3
b = 2.4
c = 3.5
d = 7.88
Print " a b c d"
Print a; " "; b; " "; c; " "; d
DefInt A-Z
Dim e, f, g
e = 10.3
f = 44
g = 3.6
Print " E F G "
Print e; " "; f; " "; g
So with my echoing of the Steve's post, you can verify as declaration of type for default is in QB64.
|