[aatwo]

Hi. I read somewhere that global variables can be defined by putting them outside of any function and that in doing this you would cause them to be available across your whole program, even if it is split between files.

I tried this however received the error "Variable myVar is not within scope at line blah blah in file blah blah.....".


essentially, in a boiled down form my code is as follows:

main.cpp
Contains:
#include "file1.h"
int myVar = 0;

file1.cpp
contains:
#include "file1.h"
void myFunction(){
myVar++;
}

I then compile these into a single binary.

So my question is this: Does file1.h need to include main.cpp in order to access its globally defined variable? If not then what is the problem? To me, including my main.cpp file which contains my main(), just for 1 variable, would seem like super bad programming practice.

[taylorc8]

keyword "extern" maybe?

[JackOfAllTrades]

Do the right thing and pass the NON-GLOBAL variable to the function!

[CasGrimes]

i think it's only global to the cpp file it is declared inside, otherwise i think you need the extern declaration mentioned above.

This post has been edited by CasGrimes: 16 August 2010 - 02:54 PM

[jjl]

dont just use extern variables just because you dont know how to pass a paramter. There is one rule that you should live by when using globals

#1 Only use a global if its last resort

main.cpp

#include "file1.h"
#include <iostream>

int main()
{
     int x = 0;
     myFunction(x);

file1.h

void myFunction(int &x)
{
     x++;
}

This post has been edited by ImaSexy: 16 August 2010 - 02:59 PM

[aatwo]

The extern keyword, of course, I remember reading about that somewhere but it apparently escaped my memory. Thanks for the help!

...and yes I know all about function arguments however the code I supplied was massively simplified and taken out of context, so while passing arguments into functions is super awesome, it is much more efficient to use a global variable in my case.

regards.

[Manipulate]

Yeah global variables are a sign that you are a bit of an amateur coder. Not saying you're an amateur but using them makes it look like you are.

[jjl]

Quote

it is much more efficient to use a global variable in my case.

That statement does not make sense.

But whatever's cool with you


EDIT: why not post this code, im curious to see how difficult it would be to implement parameters

This post has been edited by ImaSexy: 16 August 2010 - 05:48 PM

[alias120]

As many others have said, you should refrain from using Globally Scoped variables. In smaller programs, you might be able to get away with a global const. When writing anything larger, you are asking for trouble. Especially with a non-descriptive name such as 'var'. You also lose all encapsulation of that variable within it's scope, anything can touch it. Though you may think that is not a problem in your particular instance, it is bad programming practice. If you want that variable to reflect the change in main.cpp, pass by reference. If you only want a copy made for that function, pass by value. These methds are simple and will make your code better to use.

[baavgai]

You can do this:

// global.h
#ifndef GLOBAL_H
#define GLOBAL_H

extern int gInt;

#endif

// global.cc
#include "global.h"

int gInt = 10;

// other1.cc
#include <iostream>
#include "global.h"
#include "other1.h"

void incGlobal1() {
	gInt++;
	std::cout << "incGlobal1 = " << gInt << std::endl;
}

One way to aleviate the evil above it to hide it in functions. This at least allows some control over the bare global.

e.g.

// global.h
#ifndef GLOBAL_H
#define GLOBAL_H

int getSharedInt();
void setSharedInt(int n);

#endif

// global.cc
#include "global.h"

static int gInt = 10;

int getSharedInt() { return gInt; }

void setSharedInt(int n) { gInt = n; }


// other1.cc
#include <iostream>
#include "global.h"
#include "other1.h"

void incGlobal1() {
	int n = getSharedInt();
	setSharedInt(++n);
	std::cout << "incGlobal1 = " << n << std::endl;
}

Now at least you can trace it, control changes, and alleviate some of the potential pain of using a global.

You can use the same trick for quasi singletons and shared structs. C++ can avoid globals with class patterns. For C, this is really the only option for a global state. Well, aside from doing it properly and passing parameters.

[aatwo]

Wow you guys reeeaaaally are against global variables. I honestly didn't realise they were so frowned up.

In all honestly I am quite new to c++ (couple of months) and my last language was javascript so it's been a big jump but I guess its knowing things like this that separate the noobs (me) from the pros (you)

I cant link you any of the code but essentially I am using the GTK gui library and I have a user interface being initialised in my main, and in separate files I have other aspects of the gui such as dialogs, message boxes etc. Now in some of these files containing the code to produce dialogs etc, I need to access certain gui objects that were created in my main.

So if I have 20 objects or variables or arrays etc that I need to access from a dialog, I would surely need to pass like 20 arguments during its creation in order to have pointers to all of these things that my dialog hypothetically needs to access.

And since most of the time many of these things will not change (but it remains important that they can be changed) it just seems more efficient to store their pointers and values in global memory.

Any thoughts?

[baavgai]

The big issue with globals is that any part of your program can change them, at any time. Figuring out who did what when is near impossible in big bowl of spaghetti code. And any code that liberally uses globals is pretty much guaranteed to be a steaming pile of debug nightmare.

Passing pointers to data costs an int and makes explicitly clear what part of the program needs what data. If there are logical groupings of data, you can pass a struct. Indeed, if you have a set of data points that are always being referenced together, it probably should be a struct.

Variables should exist for the shortest time possible. They should have the narrowest scope possible. Functions should be given only the information they need to do their job. If you can keep to this, your code can be lean, mean, and easy to clean. Globals are, by their nature, the opposite of this.

[aatwo]

Some interesting points there, thanks for the post. I am actually continuing work on a program designed in this way by a previous employee and it actually is a nightmare to debug, I expect for the reasons you mentioned.

I think I am convinced though and will try to edit out as much of the dirty global variables as I possibly can

Thanks guys.