PureBasic Forums - English

Is it possible to get access on the global variable from within the procedure while the local one is defined?

 

You could create an alias via a pointer to access it with a different name:

I am not a fan of naked global variables.
Why not use a globally defined structure and access its members anywhere?

The solutions given so far would work. 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.

Some ways to avoid conflicts include adding a prefix such as 'g_' to the names of global variables and another is to group all goal variables under a single structured variable.

@skywalk: you beat my post while mine was in progress.

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.

Yep, exactly!

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

That's what I'm doing. And I'm adding the prefix 's_' to the names of shared variables.

Thanks for the answers. So, it's not possible without some tricks. No problem.

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.

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

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 IMO

My code is unreadable and chaotic. Without having the need for I just stumbled across this question.
Same with: Why is CountCPUs a procedure and not two constants? Can they change while a program is running?

jacdelad wrote: Wed Apr 30, 2025 9:30 pm 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 10:09 pmWhy is CountCPUs a procedure and not two constants? Can they change while a program is running?

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.

For fun: you can also use the runtime library to access the global as a string name: With macros you can also use the original identifier and convert it to a string automatically: - the macro Global() doesn't seem to interfere with the regular Global keyword, but i would not advise this.
- to change the value you would need a second macro using SetRuntimeInteger()
- readability does *not* increase, to say the least but it's always interesting to see what's possible.

#NULL wrote: Thu May 01, 2025 7:10 am

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?

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.

Yeah, I suspected that. Some other languages have "dynamic" constants which are replaced on run. No problem here.

Thanks #NULL and I really appreciate all your creativity. I was just curious whether there's a predefined way to do this. Never wanted to use this.