global variables

[Kent Sarikaya]

You could call me a fan boy of using Global Variables, I always use them and I think they simplify so many tasks, but I keep reading how they should not be used.

I have been trying to figure out how to eliminate using them, but all I come up with is passing it as parameters to every function that needs to use the values, it sure seems like lots of extra work. Is there another way to handle a value used in many routines, without having to pass it as a parameters to the routine or using global as the scope?

Thanks for any tips!

[José Roca]

 
No. There is nothing wrong in using global variables if you don't intend to make your code reusable. If you want to be able to reuse the functions in another application, then avoid them.

[Charles Pegge]

If your population of global variables is fairly small, say less than 200, then that is perfectly manageable.

Another alternative is to arrange your variables into user- defined TYPES and pass these to your functions just the way it is done with many Windows calls. These types are normally passed BYREF, (which is the default mode in BASIC), only the address is passed so the call can be almost as efficient as using GLOBALs.

It all depends on the size and complexity of your program and whether you intend deploying your functions in other programmes. Having their own data structures might improve their portability.

But I find that many of my procedures require access to many 'state' variables which are shared throughout the programme, for instance when extracting a word in a script, it is useful to know its starting position, ascii code, its end position, then the  ascii code of the next word, and ascii code of the  previous word, and whether it is a number or a symbol - and which string was being read.

Similarly in a physics engine all the interacting objects need to know each other's positions, mass, velocity etc. Keeping them isolated would add to the complexity of the program.

[Jim Robinson]

There is nothing wrong using global variables as long as you are aware of the possible problems that you may encounter by using them.

I preface my global names with 'g' (like gsName, giCount, etc.) so that I will know I am dealing with a global if I need to go back and maintain the code. I generally do not use as many globals in my more complicated projects since it becomes a chore keeping track of them.  But, I will only change globals to locals if I really need to, not because someone thinks they are bad.

Like GOTO, global variables have received a bad name, and some people will tell you not to use them without knowing why.

Slightly OT: Once, as a joke, I told a COBOL programmer about a bumper sticker I saw that said "Real programmers use GOTO".  I received a 20 minute lecture on why I should not use the evil GOTO.  He was so passionate in his argument he actually turned red in the face.      (I had to listen to the lecture because he was a prospective customer.)

[Paul Squires]

In my programs I have a TYPE that holds all global variables.

For example:

Code Select Expand


TYPE GLOBAL_TYPE
  hSomething As Long
  nCount     As Long
  zString    As Asciiz Ptr
  '.... etc....
END TYPE

Global g As GLOBAL_TYPE


In my code, all I have to do is refer to the global as g.hSomething, or g.nCount, etc....

The only problem is when it comes to dealing with strings in the TYPE. Because PB does not have native support for variable length strings in a TYPE structure, I need to use my own routines for dealing with the string.

Code Select Expand


MemString g.zString, "This is my long global string"

MsgBox g.@zString


It is easy, clean, and simple to keep track of.

[Theo Gottwald]

Did you see the discussion on this topic here?

There is a clear comment from Bob Zale on the topic.
Must say that I agree with him on this point.

http://www.powerbasic.com/support/pbforums/showthread.php?t=34964

[Kent Sarikaya]

Thank you for all the feedback and ideas. Glad to know globals are not the evil coding style many seem to make it on the web.

The idea of passing globals in a UDT is very clever, THANKS. I will definitely try this. It is really a cool idea!!

[Kent Sarikaya]

Did you see the discussion on this topic here?

There is a clear comment from Bob Zale on the topic.
Must say that I agree with him on this point.

http://www.powerbasic.com/support/pbforums/showthread.php?t=34964

Thanks for the link Theo, it adds a lot of useful information to the conversation and is convenient to link from here to there in the future!

[Eros Olmi]

I discuss this in other many post but worth to remember here again.
To store any dynamic string you just need 4 bytes (a long, a dword, it doesn't matter). How? Just use on the fly (RE)DIM ... AT
Any LONG can be used to simulate an OLE32 dynamic string overimposing a dummy string structure ((RE)DIM ... AT) at the same memory location of the LONG.

Let me know if anyone need any further info on how to do it.

Ciao
Eros

[Theo Gottwald]

Eros, I remember there was some source code from you on a workaround of implementing "dynamic strings into UDT's".

Anyway all those workarounds are not the real thing :-).
I really hope we get something more easy for the user in future, no matter whats under the hood.

[Eros Olmi]

From a compiler point of view it is not easy, and I do not think dynamic strings inside UDT should be managed directly by the compiler. At the end they are just a 32bit pointer.

How can the compiler knows about the string?
After compilation, an UDT is just a sequence of bytes. If a dynamic string exists inside an UDT, the compiler need to store some special info to know that and to be able to manage accordling.

How can the compiler knows when to free allocated memory?
Ok, imagine the compiler generate code that knows, at runtime, that an UDT has one or more dynamic strings inside. I imagine that when the UDT variable is released, code takes care automatically also of the dynamic strings inside the UDT. Sometimes you allocate data but want full control of when releasing it. It happen quite often. I do not want the compiler "think" by itself!

I'm quite convinced that it is programmer responsability to deal with those data.

[Theo Gottwald]

You see, everything is possible at the end, if someone wants.

From mystandpoint as a user I, do not look on the obstacles the compiler makers have to go through.

The question for me as user is:

Can I easily rebuilt my "real-world" scenario into a "software data structure".
Because thats what its at the end about.

Questions like:
- How does the compiler make it internally to clean all the things up?
- is it difficult to adapt a SIZE() or VARPTR()?
is for the user of less interest.

If the question is: "Are UDT's with dynamic string useful" the answer is "YES".
Because IF dynamic strings are useful, then why should they not be useful in UDT's also.

Another point is, that if I look around it seems to be common for actual compilers to allow dynamic strings in UDT's (where is my Purebasic ...)?

Knowing that it can be formulated with Powerbasic as a workaround, I believed it could in the same way done "under the hood".
Even in the same reliable way. Because, if I formulate a workaround in PowerBasic and it works fine, why should it be worse if its builtin "under the hood"?

[Eros Olmi]

Yes, from a user point of view I can agree with you.

Dynamic string in UDT are possible in PureBasic?
I thought PureBasic does not even have standard variable as dynamic strings but only as ASCIIZ or fixed strings.
Are you sure? Because if this is true it will change ... "something" from my side about PureBasic consideration.

[Paul Squires]

I agree with Theo that it should be a built-in feature. Sure, there are several ways to accomplish it ourselves using pointers, but I bet that the new user would not know (or want to know) the methods of using pointers, dynamically allocated memory, or REDIM AT. I would guess that the majority of programmers do not program at the level of a Eros, Dominic, Chris, Theo, Jose, Patrice, etc...

.NET has STRUCTURE and CLASS data structures that replace TYPEs. I just looked them up on MSDN. I wonder if Microsoft cares if those data structures are saved and/or retrieved from disk? 

I just looked through my source code for FireFly 3. It is amazing how much extra code that I had to write to handle all of the variable strings in my TYPE structures. Sure, it works, but it is messy and not "BASIC" like it should be. 

I guess we'll just wait and see what Bob decides to do. I sent in my suggestion to PowerBasic support.

[Theo Gottwald]

I am not 100% sure. Thats why I searched the link to my Purebasic shortcut :-).
I thought i remember something like that.

Btw. how is that in Freebasic?

@Paul, I like your suggestion with the VTYPE because then the old "TYPE " thing can stay as it is, and the new VTYPE could have own rules.