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 18 8621
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.
"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_Keith) 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.
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
On Tue, 07 Jun 2005 11:20:11 +0100, Lawrence Kirby
<lk****@netactive.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 :-)
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)
Lawrence Kirby <lk****@netactive.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
> 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;
...
}
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.
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)
In article <9p********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes: Global const variables are, indeed, of very little use.
Certainly, to people who can't think of a use for them.
If you need some constant value that can be used in your program then you should use a #define or enum.
If I need a constant value of structure type (probably the most common
case in my code), an enum is not suitable; prior to C99 (not available
on all the platforms I need to support), neither is a macro, and macros
aren't type-safe.
Why constant values of structure type? For initialization, of course:
struct foo { /* whatever */ };
const struct foo foo0 = {0}; /* or possibly something more complex */
struct foo *MakeFoo(void)
{
struct foo *NewFoo = malloc(sizeof *NewFoo);
if (NewFoo) *NewFoo = foo0;
return NewFoo;
}
Making gross generalizations without carefully reviewing all the
likely cases leads to posts of little value. It is often appropriate
to have a constant of aggregate type. Prior to C99, C's support for
those was limited to string literals and literal initializers.
--
Michael Wojcik mi************@microfocus.com
Recently, they appeared at the reopening of the Brookdale Library,
luring passersby with the opportunity to be anonymously silly.
On 8 Jun 2005 15:44:51 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote: If I need a constant value of structure type (probably the most common case in my code), an enum is not suitable; prior to C99 (not available on all the platforms I need to support), neither is a macro, and macros aren't type-safe.
Why constant values of structure type? For initialization, of course:
struct foo { /* whatever */ }; const struct foo foo0 = {0}; /* or possibly something more complex */
struct foo *MakeFoo(void) { struct foo *NewFoo = malloc(sizeof *NewFoo); if (NewFoo) *NewFoo = foo0; return NewFoo; }
Making gross generalizations without carefully reviewing all the likely cases leads to posts of little value. It is often appropriate to have a constant of aggregate type. Prior to C99, C's support for those was limited to string literals and literal initializers.
You don't need a global const for that. Simply have your "initializer
struct" foo0 as a (static) const local in your function MakeFoo() and
thus "hide" foo0 behind the function MakeFoo().
Having the "initializer struct" as a global invites programmers to use
your foo0 directly. There will be two ways to initialize new foo
objects : using MakeFoo (the prefered way) and using foo0 directly
(not prefered since it makes it possible to have initialization
scattered across the code instead of having it in a single function). ro***********@antenova.com wrote: 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.
You can implement that sort of thing nicely with my hashlib
package, and just export a pointer to the hshfind routine, and
pointers to the hashtables proper as created by hshinit. You will
also need a type to specify the storage. Now multiple tables
require no added code. You can find hashlib at:
<http://cbfalconer.home.att.net/download/hashlib.zip>
--
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)
Lawrence Kirby <lk****@netactive.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.
I've found the following technique useful:
in some_module.h:
extern const VariableType * const global_variable_pointer;
#define global_variable (*global_variable_pointer)
in some_module.c:
static VariableType static_variable;
const VariableType * const global_variable_pointer = & static_variable;
Now 'global_variable' can be used everywhere as a read-only variable,
and 'static_variable' can be written in some_module.c to change the
contents of 'global_variable'.
In article <o7********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes: On 8 Jun 2005 15:44:51 GMT, mw*****@newsguy.com (Michael Wojcik) wrote:
If I need a constant value of structure type (probably the most common case in my code), an enum is not suitable; prior to C99 (not available on all the platforms I need to support), neither is a macro, and macros aren't type-safe.
Why constant values of structure type? For initialization, of course: You don't need a global const for that.
Obviously; removing support for global struct-type constant values
from C does not make it strictly less powerful. I don't need "while"
or "do" or "switch", either. That doesn't mean I shouldn't use them.
Simply have your "initializer struct" foo0 as a (static) const local in your function MakeFoo() and thus "hide" foo0 behind the function MakeFoo().
Oh, there's enlightenment: you can substitute local constants for
global ones! Who would have thought it?
Perhaps you might consider whether there are ever reasons to
preferring a global constant to one or more identical local ones.
Having the "initializer struct" as a global invites programmers to use your foo0 directly.
It does no such thing. Programmers will do what they will do. If
they're smart, they'll use the documented interface; if not, they
won't. Exposing an implementation detail in a header (and please
note that doesn't necessarily happen in this case anyway) doesn't
make dumb programmers any smarter, or make it any harder for them to
shoot themselves in the foot.
--
Michael Wojcik mi************@microfocus.com
Unfortunately, as a software professional, tradition requires me to spend New
Years Eve drinking alone, playing video games and sobbing uncontrollably.
-- Peter Johnson
On 9 Jun 2005 18:32:42 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote: In article <o7********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes: On 8 Jun 2005 15:44:51 GMT, mw*****@newsguy.com (Michael Wojcik) wrote:
>If I need a constant value of structure type (probably the most common >case in my code), an enum is not suitable; prior to C99 (not available >on all the platforms I need to support), neither is a macro, and macros >aren't type-safe. > >Why constant values of structure type? For initialization, of course: You don't need a global const for that.
Obviously; removing support for global struct-type constant values from C does not make it strictly less powerful. I don't need "while" or "do" or "switch", either. That doesn't mean I shouldn't use them.
Let's take "goto". It's good that C has this thing (at least, I think
so). There are situations in which "goto" can be quite handy. But it
should be used with great care (it can easily result in spaghetti code
and do even worse things). The same goes for using globals (const or
otherwise).
Reducing globals as much as possible is just a sound programming
practice. You might think it to be stupid but I've found it to be
quite efficient to adhere to. Simply have your "initializer struct" foo0 as a (static) const local in your function MakeFoo() and thus "hide" foo0 behind the function MakeFoo().
Oh, there's enlightenment: you can substitute local constants for global ones! Who would have thought it?
Well, you didn't since you think of a const global instead of a const
local in an initialization function to be a Good Thing (which it
isn't). If you don't want to "hide" data that should only be available
to a single function then, by all means, be my guest.
Perhaps you might consider whether there are ever reasons to preferring a global constant to one or more identical local ones.
Your initialization function only needed a single constant, not
several. Having the "initializer struct" as a global invites programmers to use your foo0 directly.
It does no such thing. Programmers will do what they will do. If they're smart, they'll use the documented interface; if not, they won't.
If they're smart then they use sound programming practices.
In article <qd********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes: On 9 Jun 2005 18:32:42 GMT, mw*****@newsguy.com (Michael Wojcik) wrote:In article <o7********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes: On 8 Jun 2005 15:44:51 GMT, mw*****@newsguy.com (Michael Wojcik) wrote:
>If I need a constant value of structure type (probably the most common >case in my code), an enum is not suitable; prior to C99 (not available >on all the platforms I need to support), neither is a macro, and macros >aren't type-safe. > >Why constant values of structure type? For initialization, of course:
You don't need a global const for that. Obviously; removing support for global struct-type constant values from C does not make it strictly less powerful. I don't need "while" or "do" or "switch", either. That doesn't mean I shouldn't use them.
Let's take "goto". ... The same goes for using globals (const or otherwise).
Insufficient warrant. There's no relationship between goto and
globals that justifies this argument.
Reducing globals as much as possible is just a sound programming practice. You might think it to be stupid but I've found it to be quite efficient to adhere to.
Argument by anecdote. I've seen no reason to believe your experience
(much less your reports thereof) can be usefully generalized. Oh, there's enlightenment: you can substitute local constants for global ones! Who would have thought it?
Well, you didn't since you think of a const global instead of a const local in an initialization function to be a Good Thing (which it isn't).
And we're zero for three. Perhaps you should learn logic, Paul.
That I don't advance a certain argument does not constitute evidence
that I haven't considered it.
(I'll ignore the petitio principii and tautology, since they're only
par for the course when arguing with you.) Perhaps you might consider whether there are ever reasons to preferring a global constant to one or more identical local ones.
Your initialization function only needed a single constant, not several.
Try considering harder. It does no such thing. Programmers will do what they will do. If they're smart, they'll use the documented interface; if not, they won't.
If they're smart then they use sound programming practices.
Yes, that was rather my point. Want a cracker?
--
Michael Wojcik mi************@microfocus.com
Dude, it helps to be smart if you're gonna be mean. -- Darby Conley
On 13 Jun 2005 15:25:25 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote: In article <qd********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes: On 9 Jun 2005 18:32:42 GMT, mw*****@newsguy.com (Michael Wojcik)
Programmers will do what they will do. Ifthey're smart, they'll use the documented interface; if not, they won't.
If they're smart then they use sound programming practices.
Yes, that was rather my point.
If you'd advocate sound programming practices then you wouldn't
advocate using globals where locals could have been used just as
easily.
Your example of using a const global struct for initialization was a
*bad* programming practice since it was trivial to encapsulate this
data in the initialization function, as I've shown.
Perhaps you should read a book about programming practices ("Code
Complete" is a good one).
I don't care whether you want to adhere to sound programming practices
or bad ones. But don't go advocating bad programming practices in this
group just for the sake of wanting to have an argument.
In article <id********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes: On 13 Jun 2005 15:25:25 GMT, mw*****@newsguy.com (Michael Wojcik) wrote:
If you'd advocate sound programming practices then you wouldn't advocate using globals where locals could have been used just as easily.
An unwarranted claim, until you demonstrate that a local variable is
always superior to a global variable, when both are available.
Your example of using a const global struct for initialization was a *bad* programming practice since it was trivial to encapsulate this data in the initialization function, as I've shown.
An unwarranted claim, until you demonstrate 1) an advantage to
encapsulation in this case, and 2) that such an advantage renders the
alternative "bad".
Perhaps you should read a book about programming practices ("Code Complete" is a good one).
I've read plenty, and continue to do so.
Perhaps you should think about what you've read a bit more, since
your continual turn to cliches as absolute rules suggests cargo-
cult programming rather than critical consideration of costs and
benefits.
But don't go advocating bad programming practices in this group just for the sake of wanting to have an argument.
Should I ever have an impulse to do so, I'll be sure to suppress it.
Now I'll ignore further posts from you on this topic unless and until
you demonstrate that you can present an actual argument, well-formed,
relevant, and topical. I won't be holding my breath.
--
Michael Wojcik mi************@microfocus.com
We are subdued to what we work in. (E M Forster) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: WhyteWolf |
last post by:
I'm trying to set a object as global for access through out the rest
of my script ... {a basic SQL accessing object} however if I try
calling the object from with in another object it acts as if it...
|
by: MackS |
last post by:
Hi
I'm new to Python, I've read the FAQ but still can't get the following
simple example working:
# file main_mod.py:
global_string = 'abc'
def main():
|
by: Tony Johansson |
last post by:
Hello!
I know it's bad design to use global variables. I just want to ask a
question about them.
Is global variables and global static variables the same. These are define
outside any...
|
by: inigo.villalba |
last post by:
Hi,
I hope someone can point out my error because I'm starting to lose my
hair over this. It's probably a very straigh forward error but after
only 4 hours sleep it's doing my head in. It's to do...
|
by: Lasse Vågsæther Karlsen |
last post by:
After working through a fair number of the challenges at
www.mathschallenge.net, I noticed that some long-running functions can
be helped *a lot* by caching their function results and retrieving...
| |
by: george r smith |
last post by:
In the MSDN documentation there is a reference to "the global scope". For
example
"You can declare types directly in the global scope."
I have search extensively and can not find a definition of...
|
by: mb |
last post by:
1) you can't declare anything outside of a class, enum, etc. Thus you can't
declare globals right after the namespace declaration. I just don't
understand why Microsoft decided to do away with...
|
by: ojorus |
last post by:
Hi!
Just two short questions..:
1) In a function I want to get the value of a global variable declared
outside the function. Should I use "global $variable" or $GLOBALS?
Are there any...
|
by: sunbeam |
last post by:
Short Description of the Project:
we developed a e-learning system for our students. each student has a unique username/password to view the modules he/she should view and nothing more. since we...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |