Hi. This has been lurking in my mind and now it's time to find out the answer.
Is it 'legal/ethic' to use and (heavily) reuse variables?
Like defining MyDummyBuffer DB 255 DUP (?) and using it for each and every operation that needs a ptr to a buffer.
Or is it better to define many buffers instead of one?

It's not a life-death matter but anyway... :)

Posted on 2001-07-25 15:51:37 by latigo
I often reuse variables. But sometimes I forget to clear them (like Counters). So, I don't see any problem to use a variable several times.
Posted on 2001-07-25 16:56:31 by bazik
Global reuse like that will make scaling to larger projects or code reuse harder. Why not create a local buffer?
Posted on 2001-07-25 17:23:28 by bitRAKE
Afternoon, Latigo.

I always use a mixture.

General variables; which I can use for anything/everything (e.g. one 'buffer' for most string routines),
Specific variables; which I only use in their (the variables) current procedure(e.g. 'LOCAL' variables).

Of course, this usually ends up being in theory only.:grin:
When I need a Specific variable that is pre-initialized, I don't use 'LOCAL'. I just slap the variable between a '.data' and '.code' section, inside their (the variables) current procedure. This will show (hopefully) that the initialized variables are only meant to be used in the current procedure - even though they are accessible globally.

Posted on 2001-07-25 17:34:01 by Scronty

Generally variable reuse is good coding practice as long as you don't get tangled up with its use.

If you are sure a variable will not be used by the first data in the procedure again, by all means reuse it, it saves allocating more variables on the stack.

About the only problem I can see is if you reuse it and then try to use it thinking it has the earlier value in it. In a WndProc each message starts from the beginning of the proc so having a few general purpose variable on the stack works well, I use 2 128 byte buffers in the WndProc created by ProStart as it makes it easy to deal with string data without having to create one for each place where you need one.


Posted on 2001-07-26 03:58:21 by hutch--
Thank you guys :)

Posted on 2001-07-26 09:06:21 by latigo
Global variables with multiple uses are like registers.
When you call/invoke other routines, you must pay attention to whether or not you need to save and restore them.

Although the APIs don't know about your globals (unless you pass their addresses in the argument list), some APIs might cause recursion if used in callback routines (WndProc, DlgProc, etc.)

So let's say you trap WM_CLOSE, set some global data, and then invoke DestroyWindow. This causes a recursive call of the WndProc. Let's say you also trap WM_DESTROY and set the same set of global data.

Then you must establish one of three alternatives: 1) WM_CLOSE will not need the data after DestroyWindow finishes; 2) the global data must be preserved/restored (your choice of whether it's done in WM_CLOSE or WM_DESTROY); 3) the change in global data by WM_DESTROY is a desired update.
Posted on 2001-07-26 12:01:20 by tank
For such a simple thought its a good topic...

Myself, I tend to 'try' and re-use as many globals as i can, but ultimately i end up with many as my project progresses..

More receintly, I have discovered I can place these 're-used' globals into a macro file, and create separate macros within that file, tailored to the specific uses i might have.. (Project specific macro files)... The Macros themselves are hardcoded to utilize a global variable, not my program...

I have only been doing this on 2 projects, but it appears in the short term to have a far better way of keeping track of the crazyness...

Anywho.. just a brainstorm im experimenting with...

Posted on 2001-07-26 22:37:14 by NaN