SHARED statement - Printable Version

SHARED statement - Printable Version

+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2)
+--- Thread: SHARED statement (/showthread.php?tid=1550)

SHARED statement - TerryRitchie - 03-14-2023

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?

RE: SHARED statement - bplus - 03-14-2023

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

RE: SHARED statement - RhoSigma - 03-14-2023

Big Grin

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.

RE: SHARED statement - Kernelpanic - 03-14-2023

(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. . .
[Image: 04618-delaforce-fine-white-port-portwein...rtugal.png]

[Image: 04618-delaforce-fine-white-port-portwein...rtugal.png]

RE: SHARED statement - SMcNeill - 03-15-2023

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

RE: SHARED statement - TerryRitchie - 03-15-2023

(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.

RE: SHARED statement - mnrvovrfc - 03-15-2023

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. Shy

RE: SHARED statement - SMcNeill - 03-15-2023

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.

RE: SHARED statement - TempodiBasic - 03-19-2023

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.