Should the GLOBAL statement be done away with?

[Frank Ferrell]

Greetings ....

For the many years that I programmed with PowerBasic DOS (2.1, 3.2 and 3.5), I needed a few global variables available throughout an entire program, usually for purposes such as program control, display/file save/printing options, security access to certain items and many other needs. These global variables were defined at the beginning of each PB-DOS program with the SHARED statement.

When using the PowerBasic Console Compiler, programmers have the option of defining global variables with the GLOBAL statement, and this is usually done at the beginning of each PB-CC program.

Now that I've taken my first baby steps with PB-CC, I have found that I do not seem to need global variables for any reason - at least the need hasn't arisen. Instead, I am creating functions (with FUNCTION/END FUNCTION) that can control various aspects of any given program much better (for me) than global variables.

Functions can return a numeric or string value just like variables, and they are always available for usage anywhere in a given program. Because of their ability to accept one or more arguments passed to them, functions be controlled in terms of what specific value needs to be returned. The returned value will in turn determine what the program is to do next.

So I wonder - are GLOBALs really necessary? If they are, then why?

[Mel Bishop]

>>>...Should the GLOBAL statement be done away with?...<<<

No.

[Roger Garstang]

I second a NO. There are still many cases where they are needed. Sure, I've wrote lots of little utilities that didn't need them, but if you "never" need them then you aren't developing anything major yet...

[Dale Yarker]

No.

Maybe I'll have time to post some reasons after work today.

Cheers,

[Chris Boss]

Global variables are an absolute necessity!

I use them all the time in GUI based apps.

Simply put, Global variables allow sharing data between functions and subs. How else would that be done without global variables ?

Some data at times needs to be universally available throughout a program.

Just because one person rarely uses Global variables does not mean they are useless. I surely couldn't live without Global variables in my PB apps.

[Walter Henn]

No! PowerBasic will never drop the GLOBAL or LOCAL statements. And why would you want them to? They give the programmer more flexibility in writing code, and that's not a bad thing.

[Joe Byrne]

Functions are not a replacement for global variables. It may appear that way, but they are not equal.

I know a few "purists" would like to say that Globals should never be used, but in the real world, they often present the best option. Sure, one could get by without global variables, but the extra code and overhead is totally unjustifiable. Now, the converse is true too. You don't want to go over-board with them.

There are some who would never use GOTO/GOSUB either, but I have come across a few occasions (albeit rare) that these are very valid and useful options.

[Clay Clear]

I agree with Joe. Well said, Joe.

[Knuth Konrad]

Without knowing how and what for you used your GLOBALs in DOS programming, that question is a bit pointless.

The point on GLOBALs is: use them wisely and sparse for meaningfull cases. I use them mostly for flags (user quits app while some threads are running) or for storing config data which should be present throughout the application.

Abusing globals for lazy data keeping is of course bad practice. To rephrase an old wisdom: Use variables as local as possible and as global as necessary.

[jcfuller]

Global variables are an absolute necessity!

I use them all the time in GUI based apps.

Simply put, Global variables allow sharing data between functions and subs. How else would that be done without global variables ?

Some data at times needs to be universally available throughout a program.

Just because one person rarely uses Global variables does not mean they are useless. I surely couldn't live without Global variables in my PB apps.

You NEVER have to use globals if you don't want to!
James

#COMPILE EXE
#DIM ALL

FUNCTION GetVar1(OPT param AS LONG)AS LONG
    STATIC Var1 AS LONG
    IF VARPTR(param) THEN
        Var1 = param
    END IF
    FUNCTION = Var1
END FUNCTION
FUNCTION PBMAIN () AS LONG
   LOCAL Var1 AS LONG
   GetVar1(22)

   Var1 = GetVar1
   PRINT Var1
   
   WAITKEY$
    

END FUNCTION

[Frank Ferrell]

Greetings ....

Thanks to all who have replied so far.

As said before, I'm new to PB-CC, and learning a little bit more about it as I go.

It is true that in PB-DOS, I used global variables to share certain info between various SUBs. But now in PB-CC, I find that carefully constructed argument pass-down sequences from one SUB to another work quite well. I am not (as of now) writing very large programs (what's that - 25,000 lines; 100,000; 500,000; maybe, One Million?), so speed and memory are not big concerns.

If globals are your thing and they work for you - fine. It's just that I haven't yet found a case in PB-CC where I need them.

[Roger Garstang]

You NEVER have to use globals if you don't want to!
James

#COMPILE EXE
#DIM ALL

FUNCTION GetVar1(OPT param AS LONG)AS LONG
    STATIC Var1 AS LONG
    IF VARPTR(param) THEN
        Var1 = param
    END IF
    FUNCTION = Var1
END FUNCTION
FUNCTION PBMAIN () AS LONG
   LOCAL Var1 AS LONG
   GetVar1(22)

   Var1 = GetVar1
   PRINT Var1
   
   WAITKEY$
    

END FUNCTION

That just covers it up by making it look like a Class/OO. When really...Static is the same thing as having a global. It retains its memory address, and if you really wanted to mess things up you could pass a pointer to its address to use it outside its Function bounds.

[Michael Mattias]

No.

MCM

[Rodney Hicks]

Why would anyone suggest doing away with a tool in the toolbox just because they don't use it?
It's not like you're carting along extra weight from jobsite to jobsite. There are many statements, features, and functions in PB that I have never used that I will likely never use, but that doesn't mean they shouldn't be in the toolbox.
There are also statements, features, and functions in PB that I have seen others use in manners that I know I would never have thought of simply because they are working in fields that I don't go near.
Some of the arguments for not using GLOBAL would also be arguments for not using UDTs. These very useful creatures confuse the hell out of me when I create them myself, and are usually totally incomprehensible when I see them in the code of others. Strangely, only mine seem to confuse the compiler.
But because I have a mental block or an innate fear concerning UDTs, I'm not going to advocate getting rid of them, nor others not using them. But specifically, nor will I question whether or not they should be included in the toolbox.
While a programmer's forte may be creating programs without the use of GLOBALs, that is fine for programs that are written for the programmer's frame of reference or use.
Hiding a value that has global or far reaching significance in a function or behind pointers does not necessarily make anyone a better programmer if the code becomes unrecognizable to others that may have to work with it.

[jcfuller]

That just covers it up by making it look like a Class/OO. When really...Static is the same thing as having a global. It retains its memory address, and if you really wanted to mess things up you could pass a pointer to its address to use it outside its Function bounds.

The point was you do not HAVE to use GLOBALS. Would I use this through out a program. NO! there are other ways to eliminate globals. Do I use GLOBALS. Yes of course and I have one source where almost all are GLOBALS. A real nightmare let me tell you.

BUT they are not really the same thing!

Senerio:

You have source code that you include that has, and uses a GLOBAL variable.
In another module you just happen to declare another GLOBAL variable with the same name and type (no error thrown by the compiler) and then try to find out why things are a bit screwy??

Using the above you get a duplicate name definition error.


James

[Rodney Hicks]

jcfuller wrote:

In another module you just happen to declare another GLOBAL variable

Instead of blaming GLOBAL for the problem, why not blame the use of modules.
There are a host of errors that can creep into code if someone forgets what is in the module, been so long since they created it. GLOBAL is just one of them.(They JUMP in on me when I forget I wrote ten lines previously.)

Anything in the module can be duplicated and either cause an error caught by the compiler and possibly not caught by the compiler.

That is not a good reason not to use GLOBAL. It's more of a good reason not to use modules.

I think the best idea would be to keep all the tools and advise careful and judicious use of same.

However, if you have a quirk, i.e. can't handle GLOBAL, you can make your remedial suggestion available to others that may have the same quirk but don't advocate disposal or avoidance of a tool on that basis.

[Mark Strickland]

If everything was ...

If everything was a nail then you would only need a hammer.

Take away my GLOBALS and I would have to be a Visual Studio programmer!

[Chris Boss]

JC,

Your solution of using a function to replace Global variables is not valuable.

Why ?

Simply put, speed.

The extra overhead of a function simply to get global data is a waste of CPU time.

In my code, I often use Global variables in time critical code. Access speed is critical and to add the overhead of a function simply to access the data would be painfully slow in comparison.

In the so called OOP world, coding styles used are suppose to make things easier. But in reality they often add extra overhead which only slows down applications and I don't think they really improve code design that much.

As I said, Global variables are a necessity.

It amazes me that with the increase of CPU speed we have today, how slow each new version of Windows gets. I use to run Windows 95 on a 586 CPU (100 mhz) with 8 meg RAM and it ran great. Personally I feel that with all the hardware advances we have today, most of it is lost because of bloated software. OOP and COM may be part of the reason. With a 2 to 3 ghz CPU software should fly, but sadly it doesn't.

One of the reasons I like PowerBasic is its speed. The command set also gives me tools to write code which is as fast as possible.

Global variables is an example of a useful tool which improves overall speed (surely better than a function).

Even the lowly GOTO and GOSUB (even ON GOSUB) are also very valuable tools in writing fast code.

BASIC has often been viewed negatively because it maintains constructs which some consider obsolete. This view often comes from those who promote OOP. Not that OPP doesn't have value, but it is only a tool which fits a specific need, just not the answer to all problems though.

If Windows had been written in PowerBasic, likely it would be much, much smaller, require much less RAM and would work on yesterdays hardware. On todays hardware it would fly!

[Michael Mattias]

The extra overhead of a function simply to get global data is a waste of CPU time.

I'm not an assembly-language guy, but isn't that "extra overhead" simply a PUSH and a POP?

Oh, Hurt me!

[Chris Boss]

Just as a reference:

In my EZGUI 4.0 Pro runtime DLL (about 30,000 lines of code)
I use:

- about 400 Global variables
- GOSUB 230 times
- GOTO 4 times

Note: My Turtle Graphic control DLL uses ON GOSUB which is critical to its speed.