Is it that bad to initialize global variables at outside?

[vib]

Hi there,

By chance, I came to learn that it is bad programming practice to
initialize global variables at outside of programs. Is it that bad? In
order to fullfil this, I had to declare them with const, but thereafter
they are no longer variables. Just couldn't see the benefits of this
practice. Any comments or advices are welcome.

Thanks
vib

[Paul Mesken]

On 6 Jun 2005 06:14:04 -0700, "vib" <vi*****@gmail. com> wrote:

Hi there,

By chance, I came to learn that it is bad programming practice to
initialize global variables at outside of programs. Is it that bad? In
order to fullfil this, I had to declare them with const, but thereafter
they are no longer variables. Just couldn't see the benefits of this
practice. Any comments or advices are welcome.

Global const variables are, indeed, of very little use. If you need
some constant value that can be used in your program then you should
use a #define or enum.

The book "Code Complete" (McConnel, now in its 2nd edition) lists
reasons to avoid global variables and some reasons in which they can
be handy. In general, they should be avoided if there is an
alternative.

[Keith Thompson]

"vib" <vi*****@gmail. com> writes:

By chance, I came to learn that it is bad programming practice to
initialize global variables at outside of programs. Is it that bad? In
order to fullfil this, I had to declare them with const, but thereafter
they are no longer variables. Just couldn't see the benefits of this
practice. Any comments or advices are welcome.

Initializing them or not isn't really the issue. Global variables
themselves can cause problems. For example, if a function
communicates only with its caller, and only via its parameters and
return value, it's relatively easy to analyze what it does. If it
also uses global variables, it can affect, and be affected by, any
other functions that use the same global variables, even in the
absence of an explicit call. The graph of dependencies among the
various functions in your program, which would otherwise have been a
simple tree structure, becomes a bowl of spaghetti.

If you need to use global variables, go ahead and use them (just be
careful). And if you're going to declare a global variable, it
usually makes sense to initialize it, just like any other variable.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Lawrence Kirby]

On Mon, 06 Jun 2005 15:36:05 +0200, Paul Mesken wrote:

On 6 Jun 2005 06:14:04 -0700, "vib" <vi*****@gmail. com> wrote:

Hi there,

By chance, I came to learn that it is bad programming practice to
initialize global variables at outside of programs. Is it that bad? In
order to fullfil this, I had to declare them with const, but thereafter
they are no longer variables. Just couldn't see the benefits of this
practice. Any comments or advices are welcome.
Global const variables are, indeed, of very little use.

They can provide information for the rest of the program.
If you need
some constant value that can be used in your program then you should
use a #define or enum.

These are simpler in a lot of cases, but other than that I don't see a
strong reason to use them in preference.

The book "Code Complete" (McConnel, now in its 2nd edition) lists

reasons to avoid global variables and some reasons in which they can
be handy. In general, they should be avoided if there is an
alternative.

The problems with global variables are much reduced if they are const.
many people would say that macros are pretty nasty, a very blunt tool
sweeping over issues of scope, namespace etc. Just because there may be an
alternative to global variables doesn't mean it is a better one.

A reasonable use of global variables can be a write once or in one place,
read anywhere approach e.g. for config data. It is a pity that C doesn't
provide an easy way to enforce this.

Lawrence

[Paul Mesken]

On Tue, 07 Jun 2005 11:20:11 +0100, Lawrence Kirby
<lk****@netacti ve.co.uk> wrote:

On Mon, 06 Jun 2005 15:36:05 +0200, Paul Mesken wrote:

If you need
some constant value that can be used in your program then you should
use a #define or enum.

These are simpler in a lot of cases, but other than that I don't see a
strong reason to use them in preference.

One of the reasons I could think of is that an attempt to modify a
const object (indirectly) results in undefined behaviour, which may
very well turn out to be that the const object is simply modified as
if it didn't have the qualifier "const" at all. Such things have the
danger of turning into programming habits.

Also, a const is not a "constant expression" so its use is a bit more
limited in this respect (its value cannot be used in compile time).

All in all, I think that the "global const vs. #define" debate is a
bit like the "goto debate". There might be cases in which global
consts are prefered but, I suspect, not many :-)

[CBFalconer]

Lawrence Kirby wrote:

.... snip ...
A reasonable use of global variables can be a write once or in one
place, read anywhere approach e.g. for config data. It is a pity
that C doesn't provide an easy way to enforce this.

Something I have been known to do:

const stuffT *thingummy(void )
{
static stuffT *data;

if (!data) {
/* code to malloc and initialize data */
}
return data;
}

Adjust nomenclature to suit.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt >
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware. com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)

[Ben Pfaff]

Lawrence Kirby <lk****@netacti ve.co.uk> writes:

A reasonable use of global variables can be a write once or in one place,
read anywhere approach e.g. for config data. It is a pity that C doesn't
provide an easy way to enforce this.

A reasonable alternative can be a function that initializes a
piece of data on its first call and returns the data or its
address on every call.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield

[vib]

>

const stuffT *thingummy(void )
{
static stuffT *data;

if (!data) {
/* code to malloc and initialize data */
}
return data;
}

Adjust nomenclature to suit.

I think the contents of stuffT is still changable,
let say,

typedef struct {
unsigned int myInt;
} stuffT;

main()
{
const stuffT *pMyData;
stuffT newData;

pMyData = thingummy();

newData.myInt = 10;
pMyData = (stuffT *)&newData;

...
}

[robert.thorpe]

CBFalconer wrote:

Lawrence Kirby wrote:

... snip ...

A reasonable use of global variables can be a write once or in one
place, read anywhere approach e.g. for config data. It is a pity
that C doesn't provide an easy way to enforce this.

Something I have been known to do:

const stuffT *thingummy(void )
{
static stuffT *data;

if (!data) {
/* code to malloc and initialize data */
}
return data;
}

Adjust nomenclature to suit.

Another possibility is to store configuration data in a hash.
The hash can be initialized in the c file controlling config, elsewhere
the function to read from the hash is the only one exported.

This is also useful because the config file can be in the format "key .
value", making it possible to add new parameters without changing too
much code.

[CBFalconer]

vib wrote:

const stuffT *thingummy(void )
{
static stuffT *data;

if (!data) {
/* code to malloc and initialize data */
}
return data;
}

Adjust nomenclature to suit.

I think the contents of stuffT is still changable,

Please don't strip attributions of material you quote.

stuffT is a type above, not a variable. thingummy returns a
pointer to an initialized and unalterable instance of the type, and
the initialization etc. is done with code in thingummy. Nothing
except that code can get at it barring suspicious constructs (which
includes extraneous casts).
--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt >
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware. com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)