Code: Select all
Global MyVar=1
Procedure Test()
Protected MyVar=2
Debug MyVar
EndProcedure
Test()
Code: Select all
Global MyVar=1
Procedure Test()
Protected MyVar=2
Debug MyVar
EndProcedure
Test()

Code: Select all
Global MyVar=1
Global *MyVar_alias.Integer = @MyVar
Procedure Test()
Protected MyVar=2
Debug MyVar ; 2
*MyVar_alias\i + 100
Debug *MyVar_alias\i ; 101
EndProcedure
Test()
Debug MyVar ; 101
Code: Select all
Structure MyGlobalVars
myvar.i
myvar2.i
;..
EndStructure
Global mgv.MyGlobalVarsCode: Select all
Global g_myVar, g_myPoint.point, g_myString.s
Structure global_vars
myVar.i
myPoint.point
myString.s
EndStructure
Global global_vars.global_vars

Yep, exactly!Demivec wrote: Wed Apr 30, 2025 4:16 pm The real issue is choosing better variable names. If a procedure needs to access a global variable it should not name any of its local variables with the same name.
That's what I'm doing. And I'm adding the prefix 's_' to the names of shared variables.Demivec wrote: Wed Apr 30, 2025 4:16 pm Some ways to avoid conflicts include adding a prefix such as 'g_' to the names of global variables
I think that's just because it's very bad practice and something that's quite rare. I've never had this come up across multiple large PB codebases. I don't even use any special naming convention for my globals, my 10K+ LOC application has aaround 5-7 globals, a few of them being structures. Quite clean and readable IMOjacdelad wrote: Wed Apr 30, 2025 9:30 pm Just a sidenote: I just wanted to kno whether I oversaw something or not (like a reverse "Shared"). It's interesting how you all instantly give advise how to avoid it.![]()
The other solutions were given already so I touched on the one that hasn't been mentioned yet when I posted.jacdelad wrote: Wed Apr 30, 2025 9:30 pm It's interesting how you all instantly give advise how to avoid it.![]()
CPUs/Cores can be switch on/off, maybe even during runtime, at least in VMs probably. But the main reason is that constants resolve at compiletime, so they would only reflect the state of your development machine. If your compiled program runs on different computers, it needs a function to get this information at runtime.jacdelad wrote: Wed Apr 30, 2025 10:09 pmWhy is CountCPUs a procedure and not two constants? Can they change while a program is running?
Code: Select all
Global MyVar=1
Runtime MyVar
Debug GetRuntimeInteger("MyVar")
Procedure Test()
Protected MyVar=2
Debug MyVar
Debug GetRuntimeInteger("MyVar")
EndProcedure
Test()
Code: Select all
Global MyVar=1
Runtime MyVar
Macro dq
"
EndMacro
Macro Global(var)
GetRuntimeInteger(dq#var#dq)
EndMacro
Procedure Test()
Protected MyVar=2
Debug MyVar ; 2
Debug Global(MyVar) ; 1
EndProcedure
Test()
Yeah, I suspected that. Some other languages have "dynamic" constants which are replaced on run. No problem here.#NULL wrote: Thu May 01, 2025 7:10 amCPUs/Cores can be switch on/off, maybe even during runtime, at least in VMs probably. But the main reason is that constants resolve at compiletime, so they would only reflect the state of your development machine. If your compiled program runs on different computers, it needs a function to get this information at runtime.jacdelad wrote: Wed Apr 30, 2025 10:09 pmWhy is CountCPUs a procedure and not two constants? Can they change while a program is running?