PUBLIC var declaration issue

[James Bott]

I never use PUBLICs, but today I am working on someone else's code and there are PUBLIC declarations. I kept getting "ambiguous reference" warnings for the PUBLICs. I finally figured out that it was only for those PUBLICs that are also initialized in the PUBLIC declaration.

Code: Select all  Expand view  RUN

PUBLIC path:="c:\" // gives a warning
PUBLIC path          // no warning

Yet the Clipper manual clearly states:

Syntax

PUBLIC <identifier> [[:= <initializer>], ... ]

So it seems that the xHarbour compiler is issuing false warnings. Has anyone else noticed this?

I am using: xHarbour 1.2.3 Intl. (Simplex) (Build 20141106)

James

[Enrico Maria Giordano]

James,

I don't get any warning compiling this sample:

Code: Select all  Expand view  RUN

FUNCTION MAIN()

    PUBLIC cVar := "This is a test"

    RETURN NIL

EMG

[James Bott]

Enrico,

OK, I found that this does generate the warnings.

Code: Select all  Expand view  RUN

Function Main()

   PUBLIC sDate
   PUBLIC cDate:="01/01/15"
   
   sDate:="5"
   
Return nil
 

It generates warnings for both PUBLICs declared.

Then if I use MEMVAR to declare the sDate var, I still get a warning for the cDate.

Code: Select all  Expand view  RUN

Function Main()

   PUBLIC sDate
   PUBLIC cDate:="01/01/15"
   
   MEMVAR sDate
   
   sDate:="5"
   
Return nil

So the only solution seems to be not to use any PUBLICs in the same routine that they are declared.

Code: Select all  Expand view  RUN

Function Main()

   PUBLIC sDate
   PUBLIC cDate:="01/01/15"
   
   doit()
   
Return nil

Function doIt()

   MEMVAR sDate
   
   sDate:="5"
   
return nil

James

[James Bott]

It is interesting that I have about a half dozen old Clipper books here and none of them discussed this issue. So, either Clipper didn't have the issue, or it is just that nobody discussed it.

Now I remember why I don't use PUBLICs...

James

[Enrico Maria Giordano]

James,

your samples don't generate any warnings here (using latest xHarbour from SVN).

EMG

[Enrico Maria Giordano]

James,

please try to compile your samples using

Code: Select all  Expand view  RUN

harbour name.prg

You should not get any warning.

EMG

[James Bott]

Enrico,

Well, the point is that I need the warnings to find undeclared locals and privates. So, I am compiling with the /w switch.

But what I don't want to see is thousands of warnings for already declared PUBLICs.

James

[James Bott]

Even this code still gives a warning for cDate.

Code: Select all  Expand view  RUN

Function Main()

   DeclarePublics()
   
   MEMVAR cDate
   
   msgInfo( cDate )
   
Return nil

Function DeclarePublics()

   PUBLIC sDate
   PUBLIC cDate:="01/01/15"
   
return nil

So I have to do it this way to prevent the warnings.

Code: Select all  Expand view  RUN

#include "fivewin.ch"

Function Main()

   DeclarePublics()
   
   MEMVAR cDate
   
   msgInfo( cDate )
   
Return nil

Function DeclarePublics()

   PUBLIC sDate
   PUBLIC cDate
   
   MEMVAR cDate
   
   cDate:="01/01/15"
   
return nil

[Enrico Maria Giordano]

James,

ok, you have to use /a compiler switch. I used it since the very early Clipper days.

EMG

[James Bott]

Thanks Enrico, I will try it.

[James Bott]

Enrico,

OK, I was away from my computer when I last responded. Now that I have been able to lookup the /a, I remember why I don't use it. I don't want automatic memvar declarations since I am trying to document all vars used in each function. This is mainly so I can look for locals and privates that may be overriding publics. As I am sure you know these situations can be nightmares producing bugs that are extremely hard to find. Since I have stopped using publics I have not had to deal with this since (in my apps at least).

So, I am going to go with the method in my previous test posted here, to declare all the publics at the start of the program.

Thanks for your input though--you helped me find a solution.

Regards,
James

[James Bott]

Actually, I have found a simpler way with the code below. First declare as publics without assignments, then declare as memvars, then assign values. This way you will not get any warnings. For clarity in the code, I may move all that housekeeping code to another function that is called at the start of the Main() function.

Code: Select all  Expand view  RUN

#include "fivewin.ch"

Function Main()
   public cDate
   memvar cDate
   
   cDate:= dtoc(date())
   
   msgInfo( cDate )

Return nil

James

[Enrico Maria Giordano]

James,

try this with /a:

Code: Select all  Expand view  RUN

FUNCTION MAIN()

    PUBLIC cVar := "This is a test"

    RETURN NIL


FUNCTION TEST()

    ? cVar

    RETURN NIL

You will get a warning. So you can't mix local and public variables. If you want to access the public one you have to use

Code: Select all  Expand view  RUN

? M -> cVar

This way is easy to search for public and private variables in all the program code.

EMG

[Enrico Maria Giordano]

James,

MEMVAR is something similar to /a so if you don't like /a you should not use MEMVAR. I prefer M -> because it helps to identify public and private variables.

EMG

[James Bott]

Here is a simple test that shows me exactly what I was looking for. There is a warning generated for cDate in the DoSomething() function.

James

#include "fivewin.ch"

Code: Select all  Expand view  RUN

Function Main()
   public cDate
   memvar cDate
   cDate:= dtoc(date())
   
   doSomething()

Return nil

Function doSomething()
   msgInfo( cDate )       // warning generated here
return nil