Public vars vs Equates

Originally posted by Eric Pearson:
Shawn --
Are you inferring (from what you have read) that equates should be avoided? Because they are similar to public variables?
-- Eric

Eric - To answer your question, No.

What I was simply tring to do was find out why most books, etc. tell you to avoid using public vars. They all tell you not to use them or to avoid them as much as possible, but then they never go on to say why. I then noticed that equates/constants are also public vars with the differences stated above. So I just wanted to see if anyone had any idea other than what is obvious as to why.

Thanks for all for the replies.



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

[Tom Hanlin]

Originally posted by Chris Boss:
Shawn;

The reason for discouraging the use of Globals is so that your functions/procedures are truly reantrant, meaning they are not dependent upon Globals and so they will work well with Threading.

The problem is that it is nearly impossible to make a complete application without Globals, since you would be forced to pass far too many parameters to many functions to overcome the need for Globals.

Another reason to avoid Globals is that they tend to make programs harder to understand and maintain, and can introduce obscure program bugs. You can't see at a glance which functions are making use of a Global, or modifying it, which can cause problems even without threading considerations.

In many cases, it is possible to completely dispense with Globals by careful consideration of the software design and by creation of appropriate user-defined types to contain related values. In some kinds of programs, this can become more cumbersome than just using Globals, so it won't be appropriate in every case. The benefits of modularization are significant, though, so it's generally a good idea to try to use as few Globals as possible.

------------------
Tom Hanlin
PowerBASIC Staff

[Eric Pearson]

Shawn --

Are you inferring (from what you have read) that equates should be avoided? Because they are similar to public variables?

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Chris Boss]

Shawn;

The reason for discouraging the use of Globals is so that your functions/procedures are truly reantrant, meaning they are not dependent upon Globals and so they will work well with Threading.

The problem is that it is nearly impossible to make a complete application without Globals, since you would be forced to pass far too many parameters to many functions to overcome the need for Globals.

If your functions must be able to be called by Threaded code (from within your own app, not by the OS), then definitely avoid the use of Globals.

If you don't use Threads, the you can use as many Globals as you want, but just be careful how you use them. The problem with Globals is that you may get confused as to which variables are Global and which are Local and cause problems in your code.

When I write apps with "lots" of Globals, I use the following syntax when naming Globals:

GLOBAL App_MyVariable1&
GLOBAL App_MyVariable2$
GLOBAL App_MyVariable3&
GLOBAL App_MyVariable4&
GLOBAL App_MyVariable5&

I use the prefix App_ for all generic Globals.

By using a consistant Prefix for all Globals your code will be more readable and you will avoid many problems associated with the confusion between Globals and Locals.

Also, it is important to understand the nature of Windows Message engine. Many API calls generate Messages that may not be sent in the order you expect and if a Global's value is not set correctly, you may assume a Global has a value when processing a message, but maybe it does not.

A good example is the API DialogBox command:

Your code may have something like :

App_hDlg&=DialogBox(...)

You may assume that App_hDlg& will have the Dialogs handle when you process the Dialogs Messages. The problem is that this command creates a Modal Dialog and the Global variable will never be set during the entire execution of all the messages for the Dialog. You would have to set a Global variable in the %WM_INITDIALOG message, rather than use the one returned by the DialogBox function.

This type of error causes the most grief when using Globals.

This is why is is good to always test a Global to see if the value has been set.

ie.

Case %WM_INITDIALOG
     If App_hDlg&=0 then App_hDlg=hDlg   ' Use handle pass to Dialog procedure

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

Originally posted by Colin Schmidt:
Just a thought. Note that there are several hundred (thousand?) equated defined already in the win32api.inc file.

That is my point exactly.

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

[Colin Schmidt]

Just a thought. Note that there are several hundred (thousand?) equated defined already in the win32api.inc file. Thus PB must have optimize equates as they are essential to the API system. PB also removes unused equates from your program at compile time.

Colin Schmidt

------------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada

[Eric Pearson]

Shawn --

> The equate is 'read only'

That's the biggest difference... an equate is a "constant", not a "variable". An equate's value does not "vary".

I feel very confident in saying that when people recommend avoiding public (GLOBAL) variables, they are not saying that you should avoid equates. There are some similarities between the two, but the programming problems that can be caused by the use of GLOBAL variables (accidental re-use, etc.) do not apply to equates in any way.

Personally, I recommend the liberal use of numeric and string equates. They make for easily read and easily modified source code, with virtually no penalty.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited April 11, 2000).]

Question: In all books, discussions I have seen it is recommended to use as little as possible or no Public variables. How are equates different than Public variables?

* Both can be seen globally with in the program.
* The size of each is known at compile time.
* The equate is 'read only', because of this I would assume the compiler can optimize them in memory.