I've seen this trick published twice, it is something I did
as a jr. programmer years ago and since abandoned in favor of
what I feel is the correct approach. What is the group's opinion?

Problem: To define and extern some global variables required in
a project.

Trick Answer:
/* One file, Globals.h
*/
#ifdef ALLOCATE_STORAGE
#    define ITEM
#else
#    define ITEM extern
#endif

ITEM int g_var1;
ITEM char g_array[10];

Now the one file that actually needs to define these vars. #defines
ALLOCATE_STORAGE and includes Globals.h. The remaining files in the
project just include Globals.h, they get the extern'd version.

My Answer:
/* Two files, first file, Globals.c
*/
int g_var1;
char g_array[10];

/* Second file, Globals.h
*/
extern int g_var1;
extern char g_array[10];

Now we link against Globals.obj and all files include Globals.h,
the effect is the same and no tricks. Downside, I have to copy
and paste the variables from Globals.c into Globals.h and add
extern. A fine punishment for using globals in the first place
I might add.

Thanks.
- Mark A. Odell (remove thisisnotvalid. to reply via email)

On Mon, 10 Apr 2000 14:00:08 GMT, Mark A. Odell

I prefer the "trick" version, because it's self-maintaining.  It prevents
drift, when you decide to change g_var1 from int to unsigned or long, or
change the dimension of g_array, etc.
The version of the "trick" which I'm more familiar with also includes

#ifdef ALLOCATE_STORAGE
#define INIT(x) = x
#else
#define INIT(x)
#endif

so that global variables can be initialized.
--

Kenan Systems Corp., a wholly-owned subsidiary of Lucent Technologies

Thanks for the response. I just can't get past allocation of storage
in a .h file. I'd go nuts looking for these globals if I didn't know
the guy was doing this. And he didn't name it globals, it was
something application specific.

- Mark A. Odell (remove thisisnotvalid. to reply via email)

It (the trick) just isn't worth the effort.

It increases your file count and makes work harder in
a single module development/testing situtation.

Initializations become more complicated.

Separation of definition and primary place of use
reduces readability.

...

--

Graz, Austria   www.hls-software.com

Mark A. Odell a crit dans le message

My answer is quite simple

1 - Don't use writable globals
2 - If you *must* use writable globals, make them private (static) and
define some functions to regulate the access to these globals.

--
-hs- "Stove"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"Really?  When run on my machine, a printed copy of the C FAQ leaps
from the monitor and whacks me over the head.." -- Chris Mears CLC

On Tue, 11 Apr 2000 02:46:20 +0200, "-hs-"

My preference.

My implementation reality.

The "guy" I'm referring to is hawking an RTOS for embedded
systems and it is chock full of globals. So much more efficient,
you see. Poo!

Thanks for the feed back.

- Mark A. Odell (remove thisisnotvalid. to reply via email)

*** Warning: Flame bait follows.

Yeah. I feel globals have their place. If it is convenient to write without
them, I do that. If not, I'm not going to write a get/set pair just to allow
me to access it. That's as bad as the global vars themselves since the
functions would be global.

Unless:
* If the setting or interpreting of the vars might be complex, I might have
a get/set pair to massage the input/output, or...
* If some additional internal values need to be recalculated if the glo var
changes, then I might enforce it by using a get/set pair.

But, I do try to minimize their use. Esp. if it is a module of general
purpose, and my dialect of Hungarian notation uses 'G' & 'g' in front of all
globals (little g for module global, big G for program global), which makes
them pretty easy to spot.

If I start out using a glo var, and one of the above exceptions comes into
play, then I just write the get/set pair, hide the glo var. Then
search/replace the glo var access points. If I missed one, the compiler will
slap me... no harm done.

I don't usually start out writing code with the idea of speed or efficiency
in mind though. If something is going to take 10ms once in a while, so be
it. If it is going to use 256 bytes of RAM when it could be stored in 200,
so be it. If those 256 bytes are going to an array of a bazillion elements,
well, that's a different story. On the whole, I'm lazy. I'll just right it
the clear and easy way. If optimization proves necessary, then I'll look
into it. (I know, I'm a bloat-coder. Just a tool of the RAM/MPU mfgrs.)

BTW: What's so different about #defines and consts? I know the difference,
but why are they not hated in the same way global variables are? Granted,
they will not experience problems relating to setting or recalc-based-on,
but still...

For example, a define for a bit mask. That's pretty much a global variable
defining the internal structure of a stored bit. Why not have get for that?
What happens when that little bit needs to suddenly represent three
conditions instead of two? What happens if that bit now needs to become
changeable at run time?

Additional flame bait material:
I consider gotos, in some exceeding rare instances, as a perfectly valid
thing. Esp. for error recovery.

Worse still: I write code in VB sometimes! And I like it. I doubt that I'd
try to write a consumer app with it, but for internal stuff, it's great.

I'll say it for you: 'Figures -- a VB coder.'

-LZ

Not as bad, functions cannot usually be modified. And, if the simple
object becomes more difficult to calculate then the function saves
you. You can also add logging and locks to the data variable with
the functions.

I tend to the get/set pair, if performance is an issue then I
reconsider.

I use g_ for globals and s_ for module level statics, everything else
is local function level, same idea. Pointers are *pVar. That's it for
my rules.

On 8-bit micros, the const would be in ROM with a costly lookup on an
address. The enum (I never use #define's, can't be scoped, unless it's
a float) is placed in line by the compiler as a constant, this
optimization I do make on 8 bitters.

Again, I use enums when I can't bit-field it, never #defines.

I use them to get to a common exit point in a function (forward only).
Reverse gotos can almost always be removed by proper loop constructs.

No, it's good for developing little GUI de{*filter*} for my embedded
targets. Although I typically write a WinNT console app, VB would
be nice.

Thanks,

- Mark
- Mark A. Odell (remove thisisnotvalid. to reply via email)

Mark A. Odell a crit dans le message ...

Multi-tasking and writable globals are definitely incompatible. I really
don't want to maintain or even see his code.

--
-hs- "Stove"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"Really?  When run on my machine, a printed copy of the C FAQ leaps
from the monitor and whacks me over the head.." -- Chris Mears CLC

Lou Zher a crit dans le message ...

"Convenient" is not the question. "Safe" is the point.

Yes, but some (a few) callers could have a read/write access and others just
a read access. (Imagine the configuration file).
In real-life (multi-tasked embedded systems), I *don't* use writable
globals.

Agreed, but you will see that one day you will put all these globals in a
unique structure, declare the structure once at init, and finalyy give the
key (the address of the structure) only to those who are allowed to use it.
The concept of permanent data is of course useful, but not anything must be
authorized to avoid abominations.

What about librarie function that are used by several callers ? They must
definitely be independent from globals (except eventually some internal ones
for debugging)

Try multithreading and come back to reality.

I said there is a problem with "writable" globals. Read-only is never a
problem (like code).

I prefer not to think of it...

It can be. 'goto's are not for beginner.

I don't speak Very Boring.

--
-hs- "Stove"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"Really?  When run on my machine, a printed copy of the C FAQ leaps
from the monitor and whacks me over the head.." -- Chris Mears CLC