Memvar and Public variables

473 views
Skip to first unread message

clipper6

unread,
Mar 19, 2014, 1:24:04 AM3/19/14
to harbou...@googlegroups.com
Newbie here. If I were to use a public variable why is necessary to declare it as memvar. If the public variable is used in another function/proc, is it enough to just declare it as memvar or do I have to declare it again as public variable then memvar.

proc main
   memvar g
   public g

   g := "this a global variable"

   return

proc myproc
   memvar g
   public g //????

   ? g

   return

Qatan

unread,
Mar 19, 2014, 7:13:28 AM3/19/14
to harbou...@googlegroups.com
Hello,
 
>Newbie here. If I were to use a public variable why is necessary
>to declare it as memvar. If the public variable is used in another
>function/proc, is it enough to just declare it as memvar or do I
>have to declare it again as public variable then memvar.
>...
 
AFAIK you just MENVAR / PUBLIC once and it will be visible anywhere in your program.
The only think is that you can not use it before being declared (obviously...)
 
Qatan

José Quintas

unread,
Mar 19, 2014, 8:13:16 AM3/19/14
to harbou...@googlegroups.com
This is Clipper compatible, when using -w3 -es2
PRIVATE and PUBLIC need MEMVAR.

MEMVAR is only a compile statment, variables are assumed PRIVATE, but not same result as use PRIVATE.

Here a different result:

PROCEDURE Main
   MEMVAR x
   PRIVATE x := 5
   ? x
   Routine()
   ? x
   RETURN

PROCEDURE Routine()
   MEMVAR x
   PRIVATE x := 10
   ? x
   RETURN


With PRIVATE in Routine(), show 5, 10, 5
Without PRIVATE, show 5, 10, 10

José M. C. Quintas
--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

elch

unread,
Mar 19, 2014, 2:08:53 PM3/19/14
to harbou...@googlegroups.com

Hi,


in front a Tip:

avoid public and private vars, it lead to a bad programming style.


Instead use LOCAL variable as long as ever possible.

For the RARE cases you really need a 'global' variable, you can work with a

'global' static, which is valid only for this prg.


BTW, give variables a more specific name, for what this var is.

I further like to add a prefix', so i can immediate read what type this var should content.

Therefor i use a 'simplified' hungarian notation:

that letter given by VALTYPE( variable ) in lowercase as prefix for the name ......



So for your question:

declare OUTSIDE the functions ONE time a MEMVAR statement,

then the compiler know that 'g' is a public/ private in this ! example.prg,

for all places the compiler does not find another variable declaration of same name



IMHO bad style:

--

MEMVAR g


proc main

public g

g := "this a global variable"

myproc()

return


proc myproc

? g

return


proc myproc2

LOCAL g := 'this will hide here the public var'

? g

return

--



best version:

--

PROC main

LOCAL cText := "this a global variable"

cText := myfunc( cText )

? cText

return


FUNCTION myproc( cText )

? cText

cText := "my now changed text"

RETURN cMyText

--



with a prg-wide global static

--

STATIC cMyText


PROC main

cMyText := 'this a prg-wide static variable'

myproc()

RETURN


PROC myproc

? cMyText

cMyText := "my new text"

RETURN

--



HTH -- and excuse, only 'my way' as a suggest

regards

Rolf

elch

unread,
Mar 19, 2014, 2:22:39 PM3/19/14
to harbou...@googlegroups.com
addendum:

some typos ...

and use switch:
-n
to ensure: no implicit starting procedure,
else code outside functions will be collected in a function,
which the example don't want ...

regards
Rolf

José Quintas

unread,
Mar 19, 2014, 7:22:53 PM3/19/14
to harbou...@googlegroups.com
This is new for me, I like it.
I use too many private variables in reports, to user options.
Variables are valid only in report PRG, and I use too many MEMVAR on each subroutine.
Will change all.

José M. C. Quintas

Klas Engwall

unread,
Mar 19, 2014, 9:24:07 PM3/19/14
to harbou...@googlegroups.com
Hi clipper6,
Adding to what the other guys have already said, MEMVAR and FIELD are
*declarations* that tell the compiler how to resolve the g in your
example. It means the same thing as typing MEMVAR->g or FIELD->g
everywhere the g occurs. MEMVAR does *not* create the g variable. MEMVAR
and FIELD must precede any executable statements.

PUBLIC and PRIVATE are *executable statements* that *create* the
variables in question. If you use the g variable without first creating
it with a PUBLIC or PRIVATE statement, it will automatically be created
as a PRIVATE.

So to do things properly, as long as you use PUBLIC and PRIVATE
variables at all, you need to both *declare* and *create* your
variables, otherwise you will get a compiler warning. You can *declare*
your PUBLIC and PRIVATE variables as MEMVAR and your database fields as
FIELD at the top of the .prg, before any functions or procedures, and
the declarations will be valid for the entire .prg file. But you must
*create* your PUBLIC and PRIVATE variables within the body of a
procedure or function. If you use *the same* variables in other .prg
files that you call from the first one, only declare them as MEMVAR in
those other source files.

All this is described under "Statements" in the Clipper Norton Guide,
which is available here if you don't have it on your system:
http://www.ousob.com/ng/53guide/

But as Rolf also said, try to cut down on using PUBLIC and PRIVATE
variables and use LOCAL variables as much as possible instead. And
file-wide STATIC variables if it is too complicated to pass around LOCAL
variables between procedures/functions in the same .prg. It reduces the
risk of shooting yourself in your foot.

Regards,
Klas

clipper6

unread,
Mar 19, 2014, 9:58:45 PM3/19/14
to harbou...@googlegroups.com
Thanks everyone for educating me on this.

Przemyslaw Czerpak

unread,
Mar 19, 2014, 11:23:10 PM3/19/14
to harbou...@googlegroups.com
Hi,

I only add to above that declaration at top of PRG file works only
when -n switch is used. Otherwise Clipper and Harbour create procedure
with the same name as PRG file.
Harbour has an extension which do not exists in Clipper: -n2 switch
enables autodetection and if code in .prg file before 1-st explicit
function/procedure contains executable statement not only declarations
then -n switch is dropped and procedure with the same name as PRG file
is created. HBMK2 enables this switch by default.
]I also suggest to read about -a and -v switches. They are supported
by Clipper and Harbour.

best regards,
Przemek
Reply all
Reply to author
Forward
0 new messages