globals (again?)

[Dirk Bruere at NeoPax]

Is there any way I can store all my globals in one file while making
them accessible to other modules? I know I can do an extern on each one
in the relevent module, but it rather defeats the whole purpose.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Eric Sosman]

Is there any way I can store all my globals in one file while making
them accessible to other modules? I know I can do an extern on each one
in the relevent module, but it rather defeats the whole purpose.

The *only* way to make a variable definition in one file
("translation unit") visible to other files is to declare the
variable `extern' in those other files. The recommended way
to do this is to put the `extern' declarations in a .h file
and to #include that .h in the other files where the variables
must be visible. In fact, go one step further: #include it
in the file where the variables are defined, too, so the
compiler can warn you if the `extern's don't match the actual
definitions.

A word of warning, though: Restrain your enthusiasm for
global variables. They are two-edged swords that can make
your program much harder to debug and much harder to modify
than would be the case if they were not there. Some people go
so far as to say "Never use globals," which I think overstates
the case against them; "Use as few globals as is reasonably
possible" is better.

 

[Dirk Bruere at NeoPax]

The *only* way to make a variable definition in one file
("translation unit") visible to other files is to declare the
variable `extern' in those other files. The recommended way
to do this is to put the `extern' declarations in a .h file
and to #include that .h in the other files where the variables
must be visible. In fact, go one step further: #include it
in the file where the variables are defined, too, so the
compiler can warn you if the `extern's don't match the actual
definitions.

A word of warning, though: Restrain your enthusiasm for
global variables. They are two-edged swords that can make
your program much harder to debug and much harder to modify
than would be the case if they were not there. Some people go
so far as to say "Never use globals," which I think overstates
the case against them; "Use as few globals as is reasonably
possible" is better.

It's an audio DSP app which is not going to be very big as programming
projects go. I could do it in C++ with a static globals class, so maybe
that's the answer. No idea what the overhead might be though.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[jameskuyper]

Is there any way I can store all my globals in one file while making
them accessible to other modules? ...

The term "globals" is not defined in the standard. There are several
different meanings that people use. The loosest definition I've heard
is equivalent to "file scope object". A stricter definition (the one I
prefer) is "file scope object with external linkage". I'll use that
definition to interpret your question. If that's not what you meant,
let me know.

The strictest definition that I'm aware of anyone actually using is
something like "object whose identifier always refers to that object,
when used anywhere in the code", which means that the term does not
refer to any feature of C. That's because in C, you can always hide an
outer-scope declaration by declaring the same identifier with a
different meaning in an inner scope. As far as I can tell, the only
useful feature of this definition is that it allows that person to say
"C does not have globals", in flat contradiction to common usage.

Globals should generally be avoided, but can be appropriate on rare
occasions.

Yes, it's trivial to put all of your globals in the same file.
However, it's not a good idea. When globals are justified, they
generally belong in the same module as the code that is most directly
relevant to them. This is not needed in order to make that code work,
it's just a matter of good organization, which will make code
maintenance a lot easier. If you want to re-use a given module in a
different program, the globals associated with that module should go
along with the code that uses those globals, which is trivial to use
if they're already in that module.

... I know I can do an extern on each one
in the relevent module, but it rather defeats the whole purpose.

What is this "whole purpose" that is defeated by doing that, and how
is it defeated? Is it a sufficiently important purpose to justify
using an otherwise sub-optimal approach to program design?

 

[Dirk Bruere at NeoPax]

The term "globals" is not defined in the standard. There are several
different meanings that people use. The loosest definition I've heard
is equivalent to "file scope object". A stricter definition (the one I
prefer) is "file scope object with external linkage". I'll use that
definition to interpret your question. If that's not what you meant,
let me know.

The strictest definition that I'm aware of anyone actually using is
something like "object whose identifier always refers to that object,
when used anywhere in the code", which means that the term does not
refer to any feature of C. That's because in C, you can always hide an
outer-scope declaration by declaring the same identifier with a
different meaning in an inner scope. As far as I can tell, the only
useful feature of this definition is that it allows that person to say
"C does not have globals", in flat contradiction to common usage.

Globals should generally be avoided, but can be appropriate on rare
occasions.

Yes, it's trivial to put all of your globals in the same file.
However, it's not a good idea. When globals are justified, they
generally belong in the same module as the code that is most directly
relevant to them. This is not needed in order to make that code work,
it's just a matter of good organization, which will make code
maintenance a lot easier. If you want to re-use a given module in a
different program, the globals associated with that module should go
along with the code that uses those globals, which is trivial to use
if they're already in that module.


What is this "whole purpose" that is defeated by doing that, and how
is it defeated? Is it a sufficiently important purpose to justify
using an otherwise sub-optimal approach to program design?

I want a single place where I can alter all the various program setup
parameters, rather than have to pick through files.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Dirk Bruere at NeoPax]

Then you can do exactly the same thing in C.

Put this in a .h file:

#ifndef H_GLOBALS
#define H_GLOBALS

struct globals
{
int member_1;
long member_2;
float member_3;
/* and so on */
};

extern struct globals my_globals;

#endif

Include this .h file in every source file that needs to refer to the
values.

In one and only one of the source files, perhaps one that doesn't
contain anything else, named something like globals.c:

#include "globals.h"

struct globals my_globals =
{
/* initializer for member_1 */
/* etc. */
};

Done. If you ever need to change the initial values of the members,
they are all in one source file.

Also, look at the architecture of your DSP. You will generally get
better packing of the data if you order the members starting with
those of the greatest width first, down to the smaller types last.

You might also find, if you have a function that references several of
these values, you might get smaller and/or faster code doing something
like this:

void some_func(void)
{
struct globals *myp = &my_globals;

/* ... */

myp->member_1 = ...

if (myp->member_3 < SOME_CONST)
{
/* ... */
}
}

This might generate better code than multiple references to
my_global.member_1, my_globals.member_3, or even global_val_1,
global_val_3, if you don't gather them all into a structure.

To find out for sure, profile the code, or ask in and
mention your specific DSP chip. That sort of detailed, platform
specific code is off-topic here, but welcome there.

Thanks a load for that!
Sometimes my brain gets screwed moving between C, C++ and C#...

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Phil Carmody]

I want a single place where I can alter all the various program setup
parameters, rather than have to pick through files.

You might want to implement some externally-facing get/set
wrappers around the variables, and keep the variables
themselves statically declared within the implementation
file.

However, do think twice before just bundling everything
together in one file.

Phil

 

[Dirk Bruere at NeoPax]

You might want to implement some externally-facing get/set
wrappers around the variables, and keep the variables
themselves statically declared within the implementation
file.

However, do think twice before just bundling everything
together in one file.

Phil

I do it on C# progs and it works out rather well.
But the MS Express dev system is really excellent. This project feels
like re-entering the stone age even though its Visual DSP++

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Phil Carmody]

I do it on C# progs and it works out rather well.

Don't confuse "works" with "is a good design".

All of my perl scripts work, but I'd not claim more than 10% of
them had any "design" go into them, let alone good design.

But the MS Express dev system is really excellent. This project feels
like re-entering the stone age even though its Visual DSP++

That's not so weird, as bundling everything into global variables
is a design straight out of the stone age. The ferrite age, to be
precise.

Phil

 

[James Kuyper]

jameskuyper wrote: ....

I want a single place where I can alter all the various program setup
parameters, rather than have to pick through files.

"program setup parameters" sounds like it could be a reasonable category
of things to group together, depending upon what those parameters
describe. I'd put them all in a structure. If there's a lot of them, I'd
organize them into sub-structures. I wouldn't make the structure a
global, however. I know that sooner or later I'll want to write a
program that carries out processing using two different values of the
parameters in a single program, comparing the results. That's easy to do
if you pass around a pointer to the parameters structure wherever it is
needed. It's much harder if you make them globals.

 

[Dirk Bruere at NeoPax]

"program setup parameters" sounds like it could be a reasonable category
of things to group together, depending upon what those parameters
describe. I'd put them all in a structure. If there's a lot of them, I'd
organize them into sub-structures. I wouldn't make the structure a
global, however. I know that sooner or later I'll want to write a
program that carries out processing using two different values of the
parameters in a single program, comparing the results. That's easy to do
if you pass around a pointer to the parameters structure wherever it is
needed. It's much harder if you make them globals.

OK.
Actually, there's not that many globals.
Mainly arrays holding filter coefficients, main data buffers, frequency
lists, Q, bandwidths etc.

I doubt the program will exceed a 1500 lines tops.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Dirk Bruere at NeoPax]

Don't confuse "works" with "is a good design".

Well, easily maintained in that case.

All of my perl scripts work, but I'd not claim more than 10% of
them had any "design" go into them, let alone good design.

My "design" is usually a combination of top down and bottom up -
hopefully meeting somewhere in the middle

That's not so weird, as bundling everything into global variables
is a design straight out of the stone age. The ferrite age, to be
precise.

Well, embedded stuff tends to be a bit different. I would like to do a
neat job in C++ but I suspect that I might discover I had run out of
resources when it gets loaded onto real h/w.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Dirk Bruere at NeoPax]

Then why does it take more than one source file?
There's little to be gained from modularizing a trivial
program -- especially when you then turn around and
defeat the modularization by splattering globals all
over Hell's half-acre.

Something tells me you're asking all the wrong
questions.

Well, a source file with 1500 lines is a bit unwieldy.
There are, for example, separate source files for each device driver.
Then one for the filters, the initialisation of h/w and coefficients etc

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Eric Sosman]

Well, a source file with 1500 lines is a bit unwieldy.

Wieldy is in the eye of the bewieldered, I guess.

There are, for example, separate source files for each device driver.
Then one for the filters, the initialisation of h/w and coefficients etc

If they all need unstructured access to "program setup
parameters," they're too tightly tied together to justify
an illusory attempt at modularization.

 

[Dirk Bruere at NeoPax]

Wieldy is in the eye of the bewieldered, I guess.


If they all need unstructured access to "program setup
parameters," they're too tightly tied together to justify
an illusory attempt at modularization.

They are tied around a common data structure and setup parameters.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff