06-09-2023, 03:25 PM
(This post was last modified: 06-09-2023, 03:39 PM by mnrvovrfc.
Edit Reason: Dumb typos although I'm sleeping better lately
)
This explanation makes no sense. Could you clue us in on the role of the variables?
From what I could see:
"x" is global.
"x1" is seen only in module-level code at the top. With OPTION _EXPLICIT It throws an error inside SUB subx2 or subx3 because either it has to be declared as local there, or it has to be declared as DIM SHARED like "x". Without OPTION _EXPLICIT it's worthless, it's just set to zero and the compiler implies it's type SINGLE.
"x2" and "x3" are obvious.
With or without OPTION _EXPLICIT you HAVE TO USE DIM anyhow if you want global variables!
To create a variable local to a subprogram, STATIC could be used instead of DIM. In this case the variable is actually global, but its scope is only the subprogram that it is declared into. That way, in your example you could have as many variables named "x1" as you want, each to its own subprogram. They could be different types as one of them is required by the subprogram it is declared into.
I don't know what you mean by "throwaway" variables, there is no programming language that supports such a thing. A variable that has to be statically allocated always occupies memory at least as pointer. This is a terminal requirement of any compiler. A "symbol" is created by the compiler which is unique to the variable, and it's different from a line label or subprogram, and different from any method or property in OOP. It is up to the program or to the programmer (with dynamically allocated stuff) to make use of the memory a variable is assigned to beyond its pointer.
Somewhere in the Wiki there is an example with something like this:
An example of a local variable that could act like a global variable. The catch is that the variable, at first call to the subprogram, has to be checked for value of zero or empty string. If that value (according to type) is needed then it could present a problem. That case requires a variable declared "DIM SHARED" in module-level scope, and initialized in that scope and not inside any subprogram.
From what I could see:
"x" is global.
"x1" is seen only in module-level code at the top. With OPTION _EXPLICIT It throws an error inside SUB subx2 or subx3 because either it has to be declared as local there, or it has to be declared as DIM SHARED like "x". Without OPTION _EXPLICIT it's worthless, it's just set to zero and the compiler implies it's type SINGLE.
"x2" and "x3" are obvious.
With or without OPTION _EXPLICIT you HAVE TO USE DIM anyhow if you want global variables!
To create a variable local to a subprogram, STATIC could be used instead of DIM. In this case the variable is actually global, but its scope is only the subprogram that it is declared into. That way, in your example you could have as many variables named "x1" as you want, each to its own subprogram. They could be different types as one of them is required by the subprogram it is declared into.
I don't know what you mean by "throwaway" variables, there is no programming language that supports such a thing. A variable that has to be statically allocated always occupies memory at least as pointer. This is a terminal requirement of any compiler. A "symbol" is created by the compiler which is unique to the variable, and it's different from a line label or subprogram, and different from any method or property in OOP. It is up to the program or to the programmer (with dynamically allocated stuff) to make use of the memory a variable is assigned to beyond its pointer.
Somewhere in the Wiki there is an example with something like this:
Code: (Select All)
SUB someprocedure ()
STATIC ready%%
IF NOT ready%% then
ready%% = NOT ready%%
'set some other variables at first run of this procedure
END IF
END SUBAn example of a local variable that could act like a global variable. The catch is that the variable, at first call to the subprogram, has to be checked for value of zero or empty string. If that value (according to type) is needed then it could present a problem. That case requires a variable declared "DIM SHARED" in module-level scope, and initialized in that scope and not inside any subprogram.