Headers and Includes: Why and How

Pages: 12
Oromis (80)
How should global variables be handled when using seperated sourcefiles?

I found you need to declare the variable again using the keyword "extern" when you need access to a global variable declared in another sourcefile. I'm to lazy to repeat that for each sourcefile in my project, so I'm using the following construction:

1
2
3
 
//global_variables.cpp

int global_var;


1
2
3
 
//global_variables.h

extern int global_var;


1
2
3
4
5
 
//sourcefile.cpp

#include "global_variables.h"

/* use the variable somewhere */


It compiles, but is it the best way to do this?
Disch (13742)
It's best to avoid globals completely for many reasons. But if you really need to, there are a few things you can do.

One way is to manipulate #defines to put the extern in:
1
2
3
 
// globals.cpp
#define GLOBAL          // #defining it here as nothing prevents 'extern'
#include "globals.h" 


1
2
3
4
5
6
 
// globals.h
#ifndef GLOBAL
#define GLOBAL extern
#endif

GLOBAL int global_var;


1
2
 
// whatever.cpp
#include "globals.h"


Or, instead of making them all global, you could throw them in a struct/class and make a singleton instance of that struct/class:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
//globals.h
struct Globals
{
public:
  int v1;
  int v2;

  inline static Globals& get()
  {
    static Globals the_globals;
    return the_globals;
  }
};

1
2
3
4
5
6
7
8
9
10
11
12
 
// whatever.cpp
#include "globals.h"

void somefunc()
{
  Globals::get().v1 = 5; // shorthand

  // alternatively
  Globals& g = Globals::get();
  g.v1 = 5;
  g.v2 = 6;
}



Latter method preferred. Though globals are hideously unorganized and should really be avoided where possible.
Oromis (80)
Oke, thanks. I will try to work around globals whenever possible, and those solutions will help me out when I can't.
Disch (13742)
Added section 8 about template classes.

weeee
kempofighter (1183)
I had a teacher "so and so" tell me not to include inside header files and I think I even read this in a C++ text but I really do like the method in this article. It seems like it will help more in the OOP approach and will help make the code more robust! Thanks for the article...


I don't understand this part of the discussion. It is impossible not to include headers inside of other headers in all cases. What does the teacher expect you to do, dynamically allocate every single object in the entire system on the heap?

You obviously have to have a strategy and include as much as possible within .cpp files. I think that it would be very difficult and unwise to never include headers within headers in a large scale app.
jsmith (5804)
Yes, that's exactly right. That used to be a paradigm some folks kept to when developing C software. A company I used to work for tried at some level to adhere to that. It basically meant you could never add anything to a "common" header file that would suddenly require every .c file to include a new header.

I agree, though, in a C++ world it makes no sense at all.

(Ok, even in a C world it still doesn't make sense to me.)
Topic archived. No new replies allowed.
Pages: 12