Can Public Functions Access All Program Variables?

[Mike Green9]

FreeBasic 1.07 Ubuntu 20.04

Hi.

Here is a sample program containing a Function GetWeight(). Is there anyway that a Function can access ALL program Variables such as Var1, Var2, and String1 in this example ?

Code: Select all

Dim As Integer Var1, Var2, Weight, W
Dim As String String1, String2

Public Function GetWeight() As Integer
    Dim As Integer Weight = 20
    Var1 = Weight * Var2                    'Defined Outside Of This Function
    String1 = "Changed in Function"    ''Defined Outside Of This Function
    Return  Weight
End Function

'   Program Begins
    Var1 = 87 :    Var2 = 12  : Weight = 11
    String1 = "String1" :  String2 = "String2"

    W = GetWeight
    Print W, Var1, Var2, String1, String2

I would also ask the same question about Sub/End Sub.

Thanks,
M....

[fxm]

Is there anyway that a Function can access ALL program Variables such as Var1, Var2, and String1 in this example ?

These variables must be declared as global (by using the 'SHARED' modifier):

Code: Select all

Dim Shared As Integer Var1, Var2, Weight
Dim As Integer W
Dim Shared As String String1
Dim As String String2

Public Function GetWeight() As Integer
    Var1 = Weight * Var2 'Defined Outside Of This Function
    String1 = "Changed in Function" ''Defined Outside Of This Function
    Return Weight
End Function

' Program Begins
Var1 = 87 : Var2 = 12 : Weight = 11
String1 = "String1" : String2 = "String2"

W = GetWeight
Print W, Var1, Var2, String1, String2

Works similarly with a Sub, or also with a private procedure.

[Mike Green9]

Awesome!. So simple.

Is there a disadvantage of declaring ALL declarative statements as Shared?

Thanks so much,
M...

[Munair]

I would make a variable global only if you intend to use it across the program (in multiple subroutines/functions).

That said, you can also use EXTERN to make a variable global:

Code: Select all

extern MyString as string
dim MyString as string

MyString = "my string"

sub MyTest()
  print MyString
end sub

MyTest()

If I remember correctly EXTERN is more optimal than SHARED.

[dodicat]

Instead of shared variables, you can put the variables in a type (structure)
Then you have a more compact way.

Code: Select all

Dim Shared As Integer Var1, Var2, Weight
Dim As Integer W
Dim Shared As String String1
Dim As String String2



Public Function GetWeight() As Integer
    Var1 = Weight * Var2 'Defined Outside Of This Function
    String1 = "Changed in Function" ''Defined Outside Of This Function
    Return Weight
End Function




' Program Begins
Var1 = 87 : Var2 = 12 : Weight = 11
String1 = "String1" : String2 = "String2"

W = GetWeight
Print W, Var1, Var2, String1, String2

''================== OTHER METHOD ===========================

type collection
      as integer var1,Var2,weight
      as string string1
end type

Public Function GetWeight2(c as collection) As Integer
    c.Var1 = c.Weight * c.Var2 
    c.String1 = "Changed in Function" 
    Return c.Weight
End Function


dim as collection c

c.Var1 = 87 : c.Var2 = 12 : c.Weight = 11
c.String1 = "String1" : String2 = "String2"
W = GetWeight2(c)
Print W, c.Var1, c.Var2, c.String1, String2
sleep

 

[coderJeff]

If I remember correctly EXTERN is more optimal than SHARED.

Not sure what you mean by optimal. Extern implies Shared; both are allocated and initialized the same way. The difference is that extern declares external linkage for visibility across multiple modules.

[Munair]

I read about this a few years ago, but I haven't been able to find it yet. It was about shared making a copy whereas extern doesn't, but I can't remember the details. I will share the link if I find it.

[jj2007]

If I remember correctly EXTERN is more optimal than SHARED.

The disassembly looks identical, for 32- and 64-bit executables.

[Munair]

Declarations on 64 bit Manjaro:

extern a as integer
dim a as integer

Code: Select all

	.file	"extern1.c"
	.intel_syntax noprefix
	.text
	.globl	A$
	.bss
	.align 8
	.type	A$, @object
	.size	A$, 8
A$:
	.zero	8
	.text

dim shared a as integer

Code: Select all

	.file	"shared.c"
	.intel_syntax noprefix
	.text
	.local	A$
	.comm	A$,8,8

Obviously, extern a is global (shared across modules).

[Vortex]

Sample.bas :

Code: Select all

Extern v As Integer

Dim Shared As Integer x

v=10

x=20

Disassembling the object module :

Code: Select all

.386
option dotname
.model flat

extern _V: dword


_text   SEGMENT PARA PUBLIC 'CODE'

_text   LABEL NEAR

_fb_ctor__sample LABEL NEAR

        mov     dword ptr [_V], 10
        mov     dword ptr [_X], 20
        ret                                             

        nop                                            
        nop                                             
        nop                                             
        nop                                             
        nop                                             
        nop                                            
        nop                                             
        nop                                           
        nop                                             
        nop                                             
        nop                                             

_text   ENDS

_data   SEGMENT DWORD PUBLIC 'DATA'

_data   ENDS

.bss    SEGMENT DWORD PUBLIC 'BSS'

_X      dd      ? 

.bss    ENDS

.ctors  SEGMENT DWORD PUBLIC 'DATA'

        dd _fb_ctor__sample       

.ctors  ENDS

END

[Developersstudio]

Yes. Any function can access any variable in the program. You can use this to your advantage by creating functions used for only for debugging purposes. If you are doing a lot of complicated calculations in your program, it would be nice to have a function that displays the values of the variables involved in the calculation so that you can watch the values change as you run the program. This can help you determine if a bug has file or memory corruption.

[badidea]

Is there a disadvantage of declaring ALL declarative statements as Shared?

If you mean 'declaring all variables shared' then: Yes, there is a disadvantage.
Image that your program grows, and you have a 100+ shared variables and lets say 40 subs/functions accessing them, you will end up with a plate of spaghetti from hell and even the most skilled Italian runs away from.

[caseih]

If he means, is there a disadvantage to declaring all variables outside of subs and functions to be global, then I disagree and state that the answer is no. In fact that is also the default in C and C++. At least in those languages, any and all variables declared outside of a function are, by definition, global to the module. Of course in C and C++, there is the concept of a main function, which FB doesn't have, but you can certainly emulate that if you desired.

[xbgtc]

Awesome!. So simple.

Is there a disadvantage of declaring ALL declarative statements as Shared?

Thanks so much,
M...

Yes. It means that once you declare them you cannot declare them again anywhere in your program eg if you're like me and like using simple quick variables like a,b,c for simple quick stuff then you have to be aware of that through out all your subs/functions else you'll be chasing bugs.

I used to dim everything shared but i saw that it wasn't good programming to have dim shared for more than say 10 variables. Better to use a type eg.

Code: Select all

type flagtype
    anim as ubyte
    animate as ubyte
    ascii as ubyte 
    bdc as ubyte
    bfreq as ubyte
    busted as ubyte
    clock as ubyte
end type

then a simple 'dim shared flag as flagtype' then you have a whole heap of shared variables with just one dim shared.

[caseih]

Sure but you can shadow any global variable you want in a function or sub. Absolutely no problem there.