global variables/passing

[sidewinder]

Currently writing a program which uses several constant values (all numbers) in main() and also in various functions. Currently I initialise and assign these values in main() and pass the required ones to each function.

As these values do not get changed would it be better/quicker to have these numbers defined as const global variables?

Thanks for the help!

[Ganon11]

That's what I would do.

[sicarie]

I don't know if the program would call for it, but I would also recommend spending some time researching the Singleton design pattern.

But it's just a thought, I'm not sure how related the variables are, or if they would lend themselves well to that pattern.

[RRick]

Another trick is to make the values as static const variables in an object. This is a lot like the Singleton, but you access the variable directly instead of retrieving an object.

Static class variables gets around the problem of using externs for global variables and the class supplies a namespace, so you can keep the variable names short and concise.

[weaknessforcats]

The problem with global const variables is that they are static. Therefore, each time you include your header in a source file you create another const variable. In a program of 500 source files, you have created 500 const variables.

Therefore: a global const variable is a no-no.

First improvement: Define a const variable in a source file this way:
[code=cpp]
extern const double PI = 3.14159;
[/code]

This creates the global variable as sharable (external linkage) and in your header you can do this:
[code=cpp]
extern const double PI;
[/code]

Now you are down to one variable.

Having got this far you are still subject to these disasters:
1) local variable hides global variable
2) name conflicts. even within namespaces.
3) exposes implementation. No redesign
4) causes race conditions in multithreaded programs
5) expands ripple when value is screwed up. every function is a suspect
6) no guarantee the user will use global
7) expands program footprint
8) memory for globals may be limited
9) no guarantee for the order of creation. Only the globals in a single file are crerated in the order of declaration. The total order is indeterminate. Hence, your global may no be there when you need it. Especially if a global object needs a global variable in another file in its constructor. aka: the initialization fiasco
10) expands ripple when a recode is needed. All the code using globals has to be changed. N=Bad if there is a large installed base.

Using name space won't help you. It just reduces the severity of some of the disasters.

At the very least put your globals in an anonymous namespace and in that file define access functions that can be called to return the values of the globals.

This is a hard-coded solution. A better way is to create a singleton object. There has alreadybeen a post on that and you shouild read that article.

[sidewinder]

The problem with global const variables is that they are static. Therefore, each time you include your header in a source file you create another const variable. In a program of 500 source files, you have created 500 const variables.

Firstly thank you for your help. However my program implements a scientific method and is contained within a single source file which I believe negates some of the disadvantages of global const variables that you have outlined.

The method is an iterative process calling several functions. Many of these functions require knowledge of some values governing a physical system. As I outlined originally these values were declared in main and the relevant ones were then passed to the functions.

I thought this to be inefficient (is it?) and was thus looking for a way to avoid continually passing these variables. The two ways I have found are global variables (which I am currently using). The other option I am looking at is to create a class (called for example variables) and have the values static members of this class.

I am sure part of my problem stems from the fact that I am new to object orientated programming and still find aspects of it confusing to day the least. Any further comments on the dis/advantages of these schemes or of any other schemes thought more appropriate are welcomed!

[weaknessforcats]

Considering your application is in one source file and presumably there is only one copy of the execution code in existence and presuming you are willing to ditch and re-code if you need to change your design, then a global variable may be all right.

The motto on my business card is: The only reality is a running program. All else is prophecy.

As I see it, the first obective is results. Results obtained by slick improvements are less important.

There is no right way. There are only these ways and those ways and perhaps some are safer than others.

[kreagan]

The motto on my business card is: The only reality is a running program. All else is prophecy.

As I see it, the first obective is results. Results obtained by slick improvements are less important.

I like that motto. But what happens if soon your program runs with a limp? Or falls down and breaks its ankle? Would you call that history or did I over look some omens and forget to talk to my soothsayer?

:)

[weaknessforcats]

I like that motto. But what happens if soon your program runs with a limp? Or falls down and breaks its ankle? Would you call that history or did I over look some omens and forget to talk to my soothsayer?

Running with a limp is better than no code at all. Falling down and breaking it's ankle?? I recall Microsoft made billions off code that blue screened if you touched the keyboard. Crappy code can always be fixed.

By prophecy is meant that if my software project hasn't produced running code, then I am making a prophecy that results will come. Trust me. The risk I run is that some competitor gets to market with an inferior product before my glorious design is fulfilled and eats the market. When I finally get to market, I find no customers. Everyone seems happy with their blue screens.

[kreagan]

Running with a limp is better than no code at all. Falling down and breaking it's ankle?? I recall Microsoft made billions off code that blue screened if you touched the keyboard. Crappy code can always be fixed.

By prophecy is meant that if my software project hasn't produced running code, then I am making a prophecy that results will come. Trust me. The risk I run is that some competitor gets to market with an inferior product before my glorious design is fulfilled and eats the market. When I finally get to market, I find no customers. Everyone seems happy with their blue screens.

lol. I know. I really do like the motto. The comment afterwards was just me being silly. It doesn't really reflect what truely happens in reality (as you showed above).