Page 1 of 1

Difference between Shared and Global...

Posted: Fri Jul 28, 2006 5:24 am
by Amiga5k
What is the purpose of Shared, if Global variables are supposed to be seen 'everywhere'? Unless I declare a variable within a procedure with the same name as a global using the 'Protected' ('Local') keyword, I see no reason for Shared.

Any thoughts?

Russell

Posted: Fri Jul 28, 2006 9:42 am
by Trond
Shared is for top-level variables declared with Define.

Posted: Fri Jul 28, 2006 9:47 am
by helpy
You do not need to define it in the top level scope. This is also possible:

Code: Select all

Procedure MyProc1()
    Shared _MySharedVar.l

    ; ...
EndProcedure

Procedure MyProc2()
    Shared _MySharedVar.l

    ; ...
EndProcedure
If you have procedures in an include file, which share some variables, they must not be defined in the top level scope.

cu, helpy

cu, helpy

Posted: Fri Jul 28, 2006 2:05 pm
by Jan Vooijs
You have four ways of programming in PB:

0) Extreme relaxed

1) Verry relaxed

2) Less relaxed

3) closed (uptight?)

I choose with intend for the ZERO as the first methode but that is because i never use that, only for very short temporary code to testing code.

Zero mode, you declare NO globals no shared only protected if you have a variable INSIDE your procedure with the same name outside. All variables without a dot letter are deamed Long (the .l at the end) or otherwise declared with "Define.s" than everything without a dot letter is a string. This is good old basic in it's most relaxed way. But very prone to 'creaping' soft errors.

The first methode is using GLOBAL so every variable is seen by all procedure's . NOTE you do NOT use SHARED!! Protected is used to shield names inside proc's for variables of the same name outside the proc.

Second: Less relaxed, now you use DEFINE for ALL your variables (note you do NOT use GLOBAL) . Now in every variable is seen in the main program but NOT inside procedure's NOW we use SHARED.

3) To be even more unrelaxed we use EnableExplicit, now every variable has to be defined AND PROTECTED AND/OR SHARED. It can be hard to write but since every variable has to be declared it helps to minimize bugs due to naming errors. Personnally I use ONLY mode 3 and it keeps your program sane. It keep development short and bugs more easy to find. The kickback is to declare every 'Tom, Dick and Harry"-variable.
NOTE we do NOT ever use GLOBAL is this mode, not even to get our code working find out why we need a global to get he code working.

I hope this helps. You can see now that SHARED really has a viable function it depends on HOW, when and where to use.

Standard rule from me is: You do NOT mix Global with Shared it does work but finding faults in your code is very hard. This is NOT an error in PB but more a programmers fault. And YES i learned it the hard way. Made that error myself in two application i made. Now they are in mode 3 uptight.

PB is wonderfull is that respact that it is capable of writing code in 4 ways. Depending on you'r needs. Short and simple use mode zero. better code goes up to mode 3 (very robust).

Using mode 3 saved me more than one time from memory leaks in programs. Or (better) finding error(s) in other peoples code. no disrespect meant more an observation.

Succes in happy programming, :)

Jan V.


(edit: the extra note at mode 3)

Posted: Sun Jul 30, 2006 2:46 am
by Amiga5k
Thanks for the replies.

To be honest, I think the importance of not using Globals has been way over played over the years: I can't think of a single instance where I've had a Global/Local conflict in all the years I've been programming - I guess I just use variables with sensible names ;)

But anyway, the definition for Shared says nothing whatsoever about 'top level variables':
Shared allows a variable, an array or a linkedlist to be accessed within a procedure. When Shared is used with an array or a linkedlist, only the name followed by '()' has to be specified.
Sounds like the definition of Global to me!

Well anyway, I guess if one were to be really strict on one's programming and disallow the use of Globals altogether, then Shared is the only way you could do it. But, as I've said, Globals are only a problem for sloppy programmers :P

Russell

Posted: Sun Jul 30, 2006 3:00 am
by netmaestro
Sounds like the definition of Global to me!
The difference is, if you have 20 procedures and one of them has a variable that is Shared, the top level loop and that procedure alone have access to the variable. The other 19 procs never heard of it. With Global, all 20 procedures have full access to the variable.

Posted: Thu Aug 03, 2006 4:41 am
by Amiga5k
This could probably be spelled out more clearly in the manual, no?

If the variable in question is already set as global in the main part of the program, then declaring it shared in a procedure would not make sense since it would already be seen by the procedure - which is why I was temporarily confused by the definition ;)

But, I have no problems with Global, so I doubt I will have a need for Shared.

Later,
Russell

Posted: Thu Aug 03, 2006 5:03 am
by Joakim Christiansen
Amiga5k wrote:But, I have no problems with Global, so I doubt I will have a need for Shared.
Same here!

Posted: Thu Aug 03, 2006 5:21 am
by netmaestro
The size of the project pretty much drives the need for different levels of scope. In a project that's less than 1 or 2 thousand lines you're probably fine to just use all global variables, but for large projects you're going to want to use Shared for variables that have no need to be recognized by the other 50-odd procedures. It helps with both performance and understandability when it comes to maintaining a project you haven't worked with for a few months.

Posted: Thu Aug 03, 2006 3:38 pm
by techjunkie
netmaestro wrote:
Sounds like the definition of Global to me!
The difference is, if you have 20 procedures and one of them has a variable that is Shared, the top level loop and that procedure alone have access to the variable. The other 19 procs never heard of it. With Global, all 20 procedures have full access to the variable.
A very good explanation! :D

Posted: Fri Aug 04, 2006 12:54 am
by Amiga5k
netmaestro wrote:The size of the project pretty much drives the need for different levels of scope. In a project that's less than 1 or 2 thousand lines you're probably fine to just use all global variables, but for large projects you're going to want to use Shared for variables that have no need to be recognized by the other 50-odd procedures. It helps with both performance and understandability when it comes to maintaining a project you haven't worked with for a few months.
I've heard this "performance hit" theory concerning Globals before, but is it really something that is worth measuring? I mean, variables, in the end, are all just pointers to some data, right? I wonder if some real world tests have been done to see the performance hit, if any, of using Globals.

Russell

Posted: Fri Aug 04, 2006 1:30 am
by chen
netmaestro wrote:
Sounds like the definition of Global to me!
The difference is, if you have 20 procedures and one of them has a variable that is Shared, the top level loop and that procedure alone have access to the variable. The other 19 procs never heard of it. With Global, all 20 procedures have full access to the variable.
who knows... knows...

Posted: Thu Aug 10, 2006 1:01 pm
by mskuma
netmaestro wrote:The difference is, if you have 20 procedures and one of them has a variable that is Shared, the top level loop and that procedure alone have access to the variable. The other 19 procs never heard of it. With Global, all 20 procedures have full access to the variable.
Only if the Global is declared above (before) all the 20 procedures. I've grappled with understanding this issue too, and was glad to see this topic. Thanks for your explanation netmaestro.

I've wondered what is the 'better' way to program something like the following:

Code: Select all

Global a.l = 10

Procedure proc1()
  Debug "inside proc1, a = " + Str(a)
EndProcedure

Procedure proc2()
  Debug "inside proc2, a = " + Str(a)
EndProcedure

Procedure proc3()
  Debug "inside proc3, a = " + Str(a)
EndProcedure

; -- main loop ---

Debug "outside, a = " + Str(a)

proc1()
proc2()
proc3()
or

Code: Select all

Procedure proc1()
  Shared a
  Debug "inside proc1, a = " + Str(a)
EndProcedure

Procedure proc2()
  Shared a
  Debug "inside proc2, a = " + Str(a)
EndProcedure

Procedure proc3()
  Shared a
  Debug "inside proc3, a = " + Str(a)
EndProcedure

; -- main loop ---

a.l = 10

Debug "outside, a = " + Str(a)

proc1()
proc2()
proc3()
as I think both are identical - maybe just a style choice. In the latter case, you can put a's declaration anywhere on the top-level scope, unlike the former (which has to go before the procedures).