what is better : Global or Shared ?

[Blue]

What is the most efficient way to keep a variable (or an array) accessible from anywhere in a large program ?
Declaring the var as Global at the start of the program or declaring it as Shared at the start of the Procedure ?

[Bisonte]

Code: Select all

DeclareModule MyProjectGlobalVars
  
  Global Variable.i
  
EndDeclareModule
Module        MyProjectGlobalVars
EndModule

To have a real global variable... also in other modules...

with MyProjectGlobalVars::Variable or with UseModule and only the variable name.

[Blue]

Thanks Bisonte for taking the time to answer… and for the useful technical advice.

But that does not really answer my question.
What I’m trying to figure is whether, to access, from within a procedure, a var declared in the main body of a program, it is better to have made that var global, or to simply make it a shared var within the procedure code.

I’m not looking for a programming technique. Just for an understanding of two different types of declarations.

[idle]

I've never understood the distinction between global and shared either.
I think it there for the sake of clarity, so you can see that a variable in the procedure is a global that has already been declared

[infratec]

The question is not 'what is better', it should be 'what is safer'?

Remember: you should always use EnableExplicit, to avoid double variables.

If you use Global with a large amount of variables, you make EnableExplicit useless for this variable names.
So it is safer to use shared.

For the running program it makes no big difference.

[BarryG]

I use Global for things like "appdir$" that never change, so that it's only written once in my source and I don't need to manually put "Shared appdir$" in every procedure that needs it. Less time-wasting and typing that way.

[ChrisR]

If a variable is used all over the place in different procedures, use Global.
On the other hand, if the variable is shared with only a few procedures, you can use Shared.
Basically It's as if it were global but only for the main program and those few procedures, but it remains local for all other procedures (a ~restricted global), not sure if I'm clear.

[PBJim]

Basically It's as if it were global but only for the main program and those few procedures, but it remains local for all other procedures (a ~restricted global), not sure if I'm clear.

Your explanation is the clearest I've read, ChrisR. This perhaps conveys a safer programming practice, in comparison with Global, because as you say, the variable remains restricted outside the scope of those procedures where it's needed.

[AZJIO]

To use "Shared" the variable must be declared with "Define", only this makes sense to use it.

Code: Select all

Define x = 9

Procedure FuncName()
	Shared x
	x = 5
EndProcedure

FuncName()
Debug x

Is a variable a pointer to data? Then there are no problems with the speed of access to the variable; there is no need to search for it in the list by name. If this is not so, then the speed of access to variables would depend on the number of variables, which means it would be beneficial to use a smaller number of global variables and some of them could be moved to the "Define" area and used with "Shared".
Judging by the fact that the variable is looked up in local and then in global, there is a suspicion that the search is taking place according to a list of variables.
If you have 100 global variables, then accessing them may be slower than if there were 5 variables. For example, a loop accesses a global variable 1,000,000 times per second, first checking for its presence in the local scope and, accordingly, it will work slowly (I haven’t tested it, testing is required). Not confirmed, the speed is the same.

[Blue]

(…) a ~restricted global), not sure if I'm clear.

Quite clear, ChrisR, and a pretty smart formulation.

Thanks also to infratec for the excellent point he raises. As he points out, for the running program, Global or Shared makes no difference, but in the course of developing a program, because it is coherent with the use of EnableExplicit, Shared is safer and, therefore, the better approach.

[Demivec]

Is a variable a pointer to data? Then there are no problems with the speed of access to the variable; there is no need to search for it in the list by name. If this is not so, then the speed of access to variables would depend on the number of variables, which means it would be beneficial to use a smaller number of global variables and some of them could be moved to the "Define" area and used with "Shared".
Judging by the fact that the variable is looked up in local and then in global, there is a suspicion that the search is taking place according to a list of variables.
If you have 100 global variables, then accessing them may be slower than if there were 5 variables. For example, a loop accesses a global variable 1,000,000 times per second, first checking for its presence in the local scope and, accordingly, it will work slowly (I haven’t tested it, testing is required). Not confirmed, the speed is the same.

The things you are referring to are this that might take place in an interpreted code but not in PureBasic which is compiled. Shared and global are the same speed and are accessed without the need to 'look them up'.

[AZJIO]

I think I understand that the address of the variable is obtained during compilation. It initially calculates the scope of the variable and assigns it a direct access address.

[idle]

Shared in my opinion is just confusing syntactic fluff that doesn't do anything it's a just a hint to the users that its a global variable. What would make more sense would be to instance them with a suffix of shared

A simulation of what I mean here with macros, where the variable is shared between two procedures. The compiler could then check the variable scopes global -> shared -> private

The variable is shared between procedures but is inaccessible in the global scope by it's defined name without a means to get_shared(x)

Code: Select all

EnableExplicit 
Global x = 1

Macro _Shared(x)  
  Global x_shared
EndMacro   

Macro set_shared(x) 
  x_shared  
EndMacro   
Macro get_shared(x) 
  x_shared
EndMacro   

Procedure foo() 
  _Shared(x) 
  set_shared(x) = 10 
EndProcedure 

Procedure  bar() 
  _Shared(x) 
  set_shared(x) = 5 
EndProcedure   

foo()
Debug get_shared(x) 
bar() 
Debug get_shared(x)  

Debug x 

[TI-994A]

What is the most efficient way to keep a variable (or an array) accessible from anywhere in a large program ?

Best coding practices would suggest against the use of globally-scoped variables with very few exceptions. Procedures usually perform some specific function and should maintain modular and reusable encapsulation. They should operate on parameters that are passed into them, usually by value, and return the processed results of those parameters. Large datasets like arrays, maps, and lists are technical exceptions because they are passed into procedures by reference, thereby reducing the duplication overhead.

The SHARED directive is a useful alternative to global declaration in cases where main-scoped variables must be shared within a procedure, for example in threads. Its use would limit the exposure of main-scoped variables and enhance the readability of the procedures themselves. However, ideally, main-scoped variables should be passed to procedures as parameters, and globally-scoped values should be restricted to the use of constants, where possible, of course.

Nevertheless, while these standards are good, they are geared more towards large-scale, professional projects, and would be quite moot in smaller programs.

[Blue]

@TI-994A : Excellent exposé. Thank you.

So, to stretch a bit the points you are raising, you would lean towards using Shared, as it appears to be the lesser of two evils.

.