PUBLIC/SHARED

[Walt Decker]

1. What is the difference between PUBLIC and SHARED?

2. Why does this work:

DEFINT A - Z

I = 19285

DIM AnArray(I) AS BYTE
PUBLIC AnArray()

CALL Prt()
END
SUB Prt
PRINT UBOUND(AnArray())
END SUB

while this produces a duplicate definition error:

DEFINT A - Z

PUBLIC AnArray() 'AS BYTE produces a syntax error
I = 19285

DIM AnArray(I) AS BYTE

CALL Prt()
END
SUB Prt
PRINT UBOUND(AnArray())
END SUB

PS: The first semantic seems like a rather unstructured approach.

[G Grant]

SHARED lets you define variables as GLOBAL within a single module
(main or UNIT code), with each module containing any number of SUBs
and/or FUNCTIONs. SHARED variables can be used by any or all SUBs
and FUNCTION within the same module without having to pass them as
parameters. To share variables among all procedures within a module,
define them as SHARED outside any SUB or FUNCTION definitions:

SHARED A%, B%, C% ;Visible to all procedures in this module now

To share variables among only a few procedures within a module, define
them as SHARED inside only the procedures that they should be shared
among, using the same variable name in each case:

SUB TEST1()
 SHARED A%, C%  ;Same A% as in TEST2(), same C% as in TEST3()
 B%=100  ;B% LOCAL and unique to this SUB
END SUB

SUB TEST2()
 SHARED A%, B%  ;Same A% as in TEST1(), same B% as in TEST3()
 C%=500  ;C% LOCAL and unique to this SUB
END SUB

SUB TEST3()
 SHARED B%, C% ;Same B% as in TEST2(), same C% as in TEST1()
 A%=256  ;A% LOCAL and unique to this SUB
END SUB

PUBLIC allows you to share variables among different modules without
having to pass them as parameters. You will have multiple modules when
you start $LINKing precompiled code to your main code (usually code
compiled as UNITs). PUBLIC variables are shared among all procedures
within a module, as well as among all modules in which those same variables
are declared as PUBLIC (you can use PUBLIC in place of EXTERNAL in UNIT
code, making it possible to store your PUBLIC statements in an $INCLUDE
file which can be used in both your main code and UNIT code). Each
variable that is declared PUBLIC in a UNIT must also be declared PUBLIC
in main (using the same variable name), or you will get an error.
Variables must be declared PUBLIC outside of any SUB or FUNCTION code.

So basically, SHARED allows you to share variables among different
procedures within a single module, and PUBLIC allows you to share
variable among different modules (and among all procedures within
those modules).


------------------

[Mel Bishop]

It took me a while to figgure this out myself.
PUBLIC is used in SUB's and FUNCTION's to make the result(x) of that sub or function available to the calling program. It must be used if you make a "canned" sub or function and compile it to a PBU for later linking to another program. Otherwise, it will not return anything (which MAY be what you want anyway). PUBLIC is not required, at least in my version (2.1f) if the sub or function is included and compiled with the main body. Only if it is compiled as a PBU.

SHARED is used to pass variable value(s) to and from a calling program. For example, consider this code:

for x = 1 to len(d$)
' do something
' do something
call a.sub.routine
' do something
' do something
next x
end

sub a.sub.routine
for x = start to finish
' do something
' do something
next x
end sub

In the above example, the values of (x) do NOT interfere with each other since the value of (x) in the SUB is private to that SUB and is not processed or passed back to the main body of the program. If on the other hand you were to have:

sub a.sub.routine
shared x
' ditto
' ditto
end sub

Now you would have a really big problem with the value of (x) in the main body of the program. Whatever the value of (x) ends up being in the SUB would be returned to the original loop and really do a number on it.

Hope this helps.



------------------

[Mike Luther]

When you do start using PUBLIC in your program to carry things
back and forth between all the various modules, remember that
they *ARE* seen in all of them. I've found that the only way
that I could keep up with it was to use a common declaration file
that has alll the stuff in it. I simply include the source for it
in everything I do and that helps keep it straight.

Yes, Bob Zale was correct that carrying 40-70 parameters back and
forth while working with SUBS is slower. However, as I was told,
PB 3.5 for DOS can only carry a total of 16 calling parameters
in your formal call conventions. Yes, I understand that one should
write small modules and use them over and over. However BIG modules
also really have to be considered which are used over and over as
well when you get to doing big things with a major suite of
programs.

Over the years and with now over 750,000 lines of PowerBASIC source
in some 106 major executables and common library units, I've been
able to halt the PUBLIC show at about 400 total PUBLIC variables.
These variables really are GLOBAL variables. They have very common
and exact same-name use spread totally over the whole suite.

Yes, there has been some discussion here in the Forum about whether
it is better to use the PUBLIC route than the discretre parameter
passing method.

And YES, the use of CHAIN techniques *IS* a valid and worthy way
of using PowerBASIC ..

All said, if the variable *IS* truly PUBLIC in what is needed, I
simply admit it, call it that, declare it as such, and add it to
the master INCLUDE file segment that I simply bind to all the
prgrams. Then, as long as I make sure that the variable type
isn't different in one place than another, things seem to have
long ago stabilized for me. With close to the 2500 variable mark
now in some program and module combinations, this was the only
way I could keep it all straight.

Your and everyone else's mileage may vary. We are all different
people and all have ways of looking at things. For me a library
is a library, even if all it holds is the names of the books!

------------------
Mike Luther
[email protected]

[G Grant]

Something I do when using PUBLIC variables is to append a trailing
underscore to the names of the PUBLIC variables (which becomes part
of the variable name), such as

DIM MYVARIABLE_ AS INTEGER
PUBLIC MYVARIABLE_

Its not an official naming convention, but as long as I stick to
using trailing underscores on ONLY PUBLIC variables, I can insure
that my PUBLIC variable names won't clash with any LOCAL variable
names. It also lets me tell at a glance which variables are PUBLIC
and which are not. Its just something I use to keep things running
smoothly.

------------------

[Mike Luther]

You .. Mr. Grant ..

are a smarter bear than I am, and you can underscore that!

grin!



------------------
Mike Luther
[email protected]

[Walt Decker]

Well, how about common? Instead of using PUBLIC which will not allow one to declare variables AS TYPE, could one use common to accomplish the same thing between MAIN and units? Would that not be a better alternative?

------------------

[G Grant]

You can declare any type of variable as PUBLIC, even user defined
types and arrays.
With user defined types, you must declare the TYPE in both main
and in each UNIT in which it is to be PUBLIC, outside of any
SUB or FUNCTION definitions:

TYPE MYTYPE
 A AS INTEGER
 B AS STRING * 10
 C AS BYTE
END TYPE

DIM MYVARIABLE AS MYTYPE
PUBLIC MYVARIABLE

This will appear in both main and in each UNIT that shares MYVARIABLE
(including the TYPE definition).

For arrays, there is a special use of the DIM statement that allows
you to declare an array without actually dimensioning it. This
allows you to describe the array to any UNIT in which the array
is to be made PUBLIC without redimensioning the array (since the
array will have already been dimensioned in main):

In main:

DIM MYVARIABLE(100, 10) AS INTEGER
PUBLIC MYVARIABLE() ;Include the parentheses with an array variable

In a UNIT:

DIM MYVARIABLE(MAX, 2) AS INTEGER ;Zero based array, 2 dimensions
PUBLIC MYVARIABLE()

MAX specifies that the array is a zero based array (only the MAXimum
array bounds are specified), and 2 specifies that it is a 2 dimensional
array. You can use MIN in place of MAX, which specifies that both the
MINimum and maximum array bounds are specified (non zero based array).
As long as the MIN or MAX keyword is used (and the number of dimensions
is specified), PowerBASIC will know that it is just a declaration
for an array, and will not dimension it (the array is, or in the case
of main WILL BE, dimensioned elsewhere). Its perfectly legal to use
this form of DIM in main (at the beginning of the code), which merely
describes how an array WILL BE dimensioned. This makes it possible
to put these DIM statements in an $INCLUDE file which can be $INCLUDEd
in both main and UNIT code.

Finally, to make a user defined type array PUBLIC:

In main:

TYPE MYTYPE
 A AS INTEGER
 B AS STRING * 10
 C AS BYTE
END TYPE

DIM MYVARIABLE(10, 20) AS MYTYPE
PUBLIC MYVARIABLE()

In a UNIT:

TYPE MYTYPE
 A AS INTEGER
 B AS STRING * 10
 C AS BYTE
END TYPE

DIM MYVARIABLE(MAX, 2) AS MYTYPE
PUBLIC MYVARIABLE()

(I normally add a trailing underscore to my PUBLIC variables to
keep them seperate from LOCAL variables, but I didn't in these
examples to avoid confusion)

------------------

[Mike Luther]

Ah yes .. Comrade Grant..

DIM MYVARIABLE(10, 20) AS MYTYPE

PUBLIC MYVARIABLE()

You can even go to the trouble of

DIM MYVARIABLE(-10 to +10, 20) as MYTYPE

And all the wonderful multiple dimension variable length string
arrays we love so well too ... etc., etc...

But wait until you try to move all this to something like C++ if
you can't get your compiler in an operating system in which you
need the resulting code for other purposes.

Be careful .. smiley .. what is so easy for us'nz here, isn't at
all so easy elsewhere!

It's like the Hotel California ..

"Goodnight said the Night Man, we are programmed to receive! You
can check out any time you like, but you can never leave!"

Leastwize not without a *LOT* of work, man ..



Kind of like the old Tom Leher song as well, "He gives the kids
free samples, because he knows full well, that today's young
innocent faces are tomorrow's clientele!"

------------------
Mike Luther
[email protected]