Control over variables inside a header file

My code is spread out over several .c files and their respective header files. I have one header file (without a .c file), which contains the definitions of some variables I wish to use in all other .c files.
In the main I wish to give these variables values.

How can I do this, so that all the other .c files will use the updated versions of the variables?

So in this header file I have something like:
double x ;

In the main I want to do something like x = 2, and make sure all the other .c files that included the header, use x=2.

You should look at the word "extern".

That's a global variable, and if it is declared in a header #included in all your .c files, then you will get what you want.

You can use extern here but it is then slightly more complicated and I'm guessing probably not necessary in this case if the header is just simple global variables like you say.

I don't generally declare variables in header files... I generally do it like this...

Code:

---

// .c file where variable originates
long x = 0; 


// .h file making it visible elsewhere
extern long x;

---

As already explained the extern keyword makes a promise to the compiler that the variable exists someplace where it is reachable. You should note that variables declared in this manner are global in scope, complete with all the problems that can bring. The use of global variables should be minimized whenever possible.

In my many attempts to fix my code I might have tried this already, but I was also using static and extern all over the place.
Now all I have in my header file is (just an example):
double x;

in my .c file:
x = 2 ;
printf("x = %f", x) ; //prints 2 like I want it to
//run some functions from other .c files that use x...
printf("x = %f", x) ; //still prints 2


Then once I call a certain function, x is changed again (to some weird number it seems).
To my knowledge I only use this x, and don't change it anywhere.
What could cause x to suddenly change again?

EDIT: Actually it doesn't appear to work at all. Those functions that I ran, which did not appear to change x, use x in their argument.
After running a function that uses x inside itself (so not through an argument), it becomes apparent that x still or again has a rubbish value.

That's because, declaring the variable in the header creates separate copies of it in each .obj file when it's compiled. Then when the program is linked you end up with "x in a.c" "x in b.c" etc.

If you declare it once in the most relevent .c file and use extern in the header, the compiler will connect them all together.

That said... it is probably a better idea to simply pass x as a parameter to your functions and/or assign it's value from the function's returns. Globalized variables are highly prone to just the kind of magic values you are describing.

Code:

---

// in the header file is (just an example):
extern double x;

// in the .c file:
double x;
// other stuff
x = 2 ;
printf("x = %f", x) ; //prints 2 like I want it to
//run some functions from other .c files that use x...
printf("x = %f", x) ; // prints result of functions

---

Or a better plan....

Code:

---


// in the .h file
double StuffInOtherFiles(double val);


// in the .c file:
double x;
// other stuff
x = 2 ;
printf("x = %f", x) ; //prints 2 like I want it to

x = StuffInOtherFiles(x);

printf("x = %f", x) ; //prints return value of function

---

It strikes me that we might be able to help you better if you posted some snippets of your actual code...

Quote:

---

Originally Posted by CommonTater

That's because, declaring the variable in the header creates separate copies of it in each .obj file when it's compiled. Then when the program is linked you end up with "x in a.c" "x in b.c" etc.

---

True, but this assumes that each .c file is being compiled as a separate object then linked together. You can also compile several .c files all together into a single object all at once, in which case the issue you describe is not a problem. It's not a good way to go for a large project, and using extern and compiling each .c file separately is probably a "better practice" of course.

Anyway, the deal with extern is that it refers to a variable that is declared somewhere else, globally but out of file scope, once, without extern. That could be in a header or in a .c. What Common Tater describes should work. If not, post all the actual declarations with the actual filenames and relevant #include declarations.

Quote:

---

Originally Posted by MK27

True, but this assumes that each .c file is being compiled as a separate object then linked together. You can also compile several .c files all together into a single object all at once, in which case the issue you describe is not a problem. It's not a good way to go for a large project, and using extern and compiling each .c file separately is probably a "better practice" of course.

---

Actually I'm pretty sure the "rule" is that each C file becomes an OBJ file, even in multi-compilers like VC++ you still end up with multiple .obj files... which are then linked into the executable. That would indicate that at compile time, each C file is considered a separate entity and thus multiple --unconnected-- copies of the variable would be created. This would also be born out by the behaviour our friend is describing... Moreover; if the compiler just mushed it all together, we would not need .h header/include files.

I seriously doubt that listing all the files on a single command line changes that.

Quote:

---

Originally Posted by CommonTater

I seriously doubt that listing all the files on a single command line changes that.

---

Here:

main.h

Code:

---

int X;

int getX();

---

main.c

Code:

---

#include <stdio.h>
#include "main.h"

int main(void) {
        int i;

        X = 10;

        for (i = 0; i<10; i++) {
                printf("%d\n", getX());
                X++;
        }

        return 0;
}

---

two.c

Code:

---

#include "main.h"

int getX() { return X; }
// you can do whatever to X here as well, it is a singular global

---

[root~/C/tmp] gcc -Wall main.c two.c
[root~/C/tmp] ./a.out
10
11
12
13
14
15
16
17
18
19

Again, not a best practice, but it does work. I'm not sure what the standard says about this so it may differ from compiler to compiler.

Quote:

---

Originally Posted by MK27

Here:

main.h

Code:

---

int X;

int getX();

---

main.c

Code:

---

#include <stdio.h>
#include "main.h"

int main(void) {
        int i;

        X = 10;

        for (i = 0; i<10; i++) {
                printf("%d\n", getX());
                X++;
        }

        return 0;
}

---

two.c

Code:

---

#include "main.h"

int getX() { return X; }

---

[root~/C/tmp] gcc -Wall main.c two.c
[root~/C/tmp] ./a.out
10
11
12
13
14
15
16
17
18
19

Again, not a best practice, but it does work. I'm not sure what the standard says about this so it may differ from compiler to compiler.

---

I'll bet you a nickel that you now have two .o files in that directory. And also, if you put int X=5 in your two.c file you'd get different answers.

EDIT: Nope, I'm wrong. GCC doesn't write out separate .o files here. (I think I used to know that, but then I forgot.) I'm pretty sure the rules for separate compilation are still followed.

Ok, now i'm getting a multiple definition error. This might be due to the inclusion of the .h files in several .c files, but if I don't do that it tells me the variables I want to use are not declared.
I'll give a few pieces of the code, maybe that'll help:
The last .c file has the error (the variable is nowhere else defined but in the constants.h).

main.c:

Code:

---

#include <stdlib.h>
#include <stdio.h>
#include <math.h>

#include "constants.h"
#include "constant_calculations.h"
#include "initial_value_calculator.h"

int main(){

  double f0_GW, r0, phi0, pr0, pphi0, m1, m2 ;
  double EOB_M, nu, v_MECO, v_pole, c_array[6], omega0;

  m1 = 1.0*phys_MO ;
  m2 = 1.0*phys_MO ;
  EOB_M  = m1 + m2 ;
  nu = m1*m2*pow(EOB_M,-2) ;
  v_MECO = calculate_vMECO(EOB_M) ;
  v_pole = calculate_vpole(nu) ;
  fill_c_array() ;

  //more stuff..

  return 0 ;
}

---

constants.h:

Code:

---

double const phys_MO = 4.94296E-6 ;

extern double c_array[6] ;

extern double EOB_M, nu;
extern double v_MECO, v_pole ;
extern double omega0;

---

constant_calculations.c:

Code:

---

#include <stdlib.h>
#include <math.h>

#include "constants.h"

double EOB_M, nu, v_MECO, v_pole, c_array[6], omega0;

//functions including calculate_vMECO(EOB_M), calculate_vpole(nu) and fill_c_array()
//fill_c_array() uses other functions which use nu inside (not in the arguments)

---

initial_value_calculator.c:

Code:

---

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

#include "constants.h"
#include "hamiltons_equations.h"
#include "reaction_force.h"

double EOB_M, nu, v_MECO, v_pole, c_array[6], omega0;

double z(double r, int diff) { //ERROR: It says at this line that it detects a multiple definition of 'phys_MO'
  double Ar,Ar_prime,X1,X2,dX1,dX2 ;

  Ar = calculate_Ar(r,0) ;
  Ar_prime = calculate_Ar(r,1) ;
  X1 = pow(r,3) * pow(Ar,2) ;
  X2 = pow(r,3) - 3*pow(r,2) + 5*nu ;
  dX1 = 2*pow(r,2)*pow(Ar,2) + 2*pow(r,3) * Ar * Ar_prime ;
  dX2 = 3*pow(r,2) - 6*r ;

  switch(diff) {
    case 1:
        return dX1/X2 - (X1/pow(X2,2)*dX2) ;
    default:
        return X1/X2 ;
  }
}

//more functions

---

One time. If you don't put extern on it in the header, then you're declaring it a lot of times -- one time every time you #include the header.

Let's consider one of the variables, EOB_M.

First, you declare it extern in "constants.h", so it needs to be declared globally in one other place. That's not what you have. Instead, you declare locally in main(), and then again, globally, in initial_value_calculator.c. So most of the other c files will be using the "EOB_M" from initial_value_calculator, but this is no doubt complicated by the fact that there is another EOB_M local to main().

As Common Tater says, what you want is this:

constants.h

Code:

---

#ifndef VAR_EOB_M
extern double EOB_M;
#define VAR_EOB_M
#endif

---

I used the include guards because you do not want this used in the file where EOB_M is actually declared without extern. That should be GLOBAL, but not in a file included in any other file (ie, a .c file, or a .h used by only one .c):

Code:

---

double EOB_M;
#define VAR_EOB_M;

---

Quote:

---

Originally Posted by tabstop

I'll bet you a nickel that you now have two .o files in that directory. And also, if you put int X=5 in your two.c file you'd get different answers.

---

Nope. I guess this really is an unusual thing to do. Anyway:

main.h

Code:

---

int X;

int getX();
void initX();

---

main.c

Code:

---

#include <stdio.h>
#include "main.h"

int main(void) {
        int i;

        initX();

        for (i = 0; i<10; i++) {
                printf("%d\n", getX());
        }

        return 0;
}

---

two.c

Code:

---

#include "main.h"

void initX() {
        X = 5;
}

int getX() {
    X++;
        return X;
}

---

[root~/C/tmp] gcc -Wall main.c two.c
[root~/C/tmp] ls
a.out main.c main.h two.c
[root~/C/tmp] ./a.out
6
7
8
9
10
11
12
13
14
15

I used to compile things this way all the time before I learned to use "make" properly; instead of a makefile I had a "compile.sh" with one long gcc call, lol. I think my first sourceforge project still works on this principle, just via autotools (ie, the makefile has only one target).

Fool around with that as much as you like, X is definitely a singular global. Looks like I'm up by $0.05 ;)

Code:

---

double const phys_MO = 4.94296E-6 ;

extern double c_array[6] ;

extern double EOB_M, nu;
extern double v_MECO, v_pole ;
extern double omega0;

---

The multple definition error is probably coming from your first double const value...
You can probably correct this with "Include Guards" in your header....

Code:

---

#ifndef CONSTANTS_H
#define CONSTANTS_H

double const phys_MO = 4.94296E-6 ;

extern double c_array[6] ;

extern double EOB_M, nu;
extern double v_MECO, v_pole ;
extern double omega0;

#endif  //CONSTANTS_H

---

This will prevent your header file from being read more than once in each compilation unit.

MK27...

The better test is to look at the value of x in each .c file...

Using your current code structure... create a function that prints the value of x from the two.c file and print it from your main...
Everything you've shown us so far is actually working on the value of X in two.c... not the one in main.

main.h

Code:

---

int X;

int getX();
void initX();

---

main.c

Code:

---

#include <stdio.h>
#include "main.h"

int main(void) {
    int i;
    X = 1234;   

    initX();

    for (i = 0; i<10; i++) {
        printf("%d  %d\n", getX(), X);       
          }

    return 0;
}

---

two.c

Code:

---

#include "main.h"

void initX() {
        X = 5;
}

int getX() {
    X++;
        return X;
}

---

@Ayreon: Here is a good explanation of many of the problems with globals, though I wager this thread has brought many of them to light for you already. Minimize their use whenever possible. You may have managed to use global variables in header files in the past by using the keyword 'static', which means each copy is visible only to the translation unit (.c file) it's in.

Defining a variable in a header file and including that header in several .c files means each .c file ends up with a global copy of that variable that will be visible by the entire program when linked. This doesn't cause problems with compilation proper (phase two of building), since that only produces disjoint object files, one for each .c file, each one with their own copy and unaware of other object files with same-named variables.

The third phase of building your program is linking, which brings all the .o files along with any libraries (or references to shared libs) together to make your executable. If there's several instances of a global variable called x, the linker can't be sure of which one is being referred to in something like x+1. If you're wondering what the first phase of building a C program is, it's pre-processing, which handles all the #includes, #ifdef, #define, etc.

If you really need global variables for something (I highly doubt you need them for your program), I recommend looking into a singleton pattern when possible. Make the variable a static global in one .c file, so no other files can see it. Provide a set of functions in that .c for accessing and manipulating that variable, and only list the prototypes for those functions in the header.

@tabstop,MK27,CommonTater:
The compiler (gcc at least) will produce one object file for each .c file, but since you have it compile all .c files straight to an executable instead of doing compilation proper in one stage, then linking in another, no .o files are produced and left in the current directory. It uses temporary files. The easy way to check is to insert a linker error in each .c file, so that it pukes when linking the object files:

main.h

Code:

---

int X;

int getX();
void initX();

---

main.c

Code:

---

#include <stdio.h>
#include "main.h"

int main(void) {
    int i;

    initX();

    for (i = 0; i<10; i++) {
        printf("%d\n", getX());
    }
    foo();

    return 0;
}

---

two.c

Code:

---

#include "main.h"

void initX() {
    X = 5;
}

int getX() {
    X++;
    foo();
    return X;
}

---

Now, when I try to compile:

Code:

---

$ gcc -Wall main.c two.c
main.c: In function ‘main’:
main.c:13: warning: implicit declaration of function ‘foo’
two.c: In function ‘getX’:
two.c:9: warning: implicit declaration of function ‘foo’
/tmp/ccd5Wtpt.o: In function `main':
main.c:(.text+0x3b): undefined reference to `foo'
/tmp/ccWxKcMk.o: In function `getX':
two.c:(.text+0x23): undefined reference to `foo'
collect2: ld returned 1 exit status

---

Two different, temporary object files, one per .c file. It would be too much work for the compiler to some how try and figure out exactly what should and shouldn't be shared between the .c files at the compilation proper stage, since that's really the linker's job anyhow. It's much easier to just compile them separately to a temporary location and let the linker link them when the time comes. It's all behind the scenes though, and no trace is left in your local directory.

Well, I learned something new today... MK27 was correct about how the X in the header becomes a single variable... The good news is that since I've been using extern in my headers... I've never run into problems because of it.

My misunderstanding seems to have come from the idea that since variables at page scope in a .c are not visible to other .c files... the ones in the header (included at compile time) would not be either...

What can I say? Nobody knows everything...

And even easier way to see what's going on with gcc is to add -save-temps to the command line. The result, as you'd expect, is two .o files (along with two .i and .s files).

Note that this trick with defining a variable in a header file only works if you don't initialize it there. Change the line in the header to "int X = 5" and you'll get a linker error about multiple definitions for X. The fact that it is that touchy is a good hint you shouldn't use it in new code - it's probably just an artifact left around to be compatible with older code which relied on this. As others have said, put the definition in a .c file and an extern in a .h file for the rest of the files which need to access it.

Quote:

---

Originally Posted by CommonTater

MK27...
The better test is to look at the value of x in each .c file...

Everything you've shown us so far is actually working on the value of X in two.c... not the one in main.

---

Yeah, my 2nd example was just an inversion of the first, I was in a bit of a rush to get out of here earlier.

However, what I've said is true, although I realize now it's unorthodox and probably not good advice. Meaning I am just trying to prove myself correct out of ego ;) As I said, I don't do this anymore -- I was assuming it's something a lot of beginners do, probably I am wrong about that. So I won't bring it up on the board again.

Here's a version where we increment X alternately in main.c and two.c:

main.h

Code:

---

int X;

int getX();
void initX();

---

main.c

Code:

---

#include <stdio.h>
#include "main.h"

int main(void) {
        int i;

        initX();

        for (i = 0; i<10; i++) {
                printf("%d\n", getX());
                X++;        // increment X in main.c
        }

        return 0;
}

---

two.c

Code:

---

#include "main.h"

void initX() {
        X = 5;
}

int getX() {
        X++;        // increment x in two.c
        return X;   
}

---

Now, if the "normal" rules applied here, this would be incrementing two different variables. But when compiled this way:

gcc main.c two.c

As I said before, that is not what happens:

[root~/C/tmp] ./a.out
6
8
10
12
14
16
18
20
22
24

Proving there is only one X in the executable -- X in main.c refers to the same variable as X in two.c.

Quote:

---

Originally Posted by KCfromNC

And even easier way to see what's going on with gcc is to add -save-temps to the command line. The result, as you'd expect, is two .o files (along with two .i and .s files).

---

Yes, but the behaviour WRT X is what it is.

Quote:

---

Note that this trick with defining a variable in a header file only works if you don't initialize it there.

---

Also true, but I wasn't suggesting it be initialized in an .h file.

Quote:

---

Originally Posted by anduril462

If you really need global variables for something (I highly doubt you need them for your program), I recommend looking into a singleton pattern when possible. Make the variable a static global in one .c file, so no other files can see it. Provide a set of functions in that .c for accessing and manipulating that variable, and only list the prototypes for those functions in the header.

---

Wouldn't that mean that every time a function in one of the other .c files uses one of the variables, that it needs to call a function that creates this variable? That's exactly what I am trying to avoid. These variables are constant from the moment they are created, it makes no sense to reacalculate them every single time they are needed in a function.

Bytheway I tried the #ifndef stuff but I still get this annoying error telling me I already defined phys_MO, I even used a seperate #ifndef for this variable. Why is it still giving me this error? This is my current constants.h:

Code:

---

#ifndef CONSTANTS_H
#define CONSTANTS_H

#ifndef VAR_PHYS_MO
#define VAR_PHYS_MO
extern double phys_MO = 4.94296E-6 ;
#endif //VAR_PHYS_MO

extern double c_array[6] ;

extern double EOB_M, nu;
extern double v_MECO, v_pole ;
extern double omega0;

#endif //CONSTANTS_H

---

It shouldn't matter how many times I include this header file right? It shouldn't even be nessecary to use #ifndef anymore around the phys_MO variable. My main.c looks like so:

Code:

---

#include "constants.h"
#include "constant_calculations.h"
#include "initial_value_calculator.h"

double EOB_M, nu, v_MECO, v_pole, c_array[6], omega0, phys_MO ;

int main(){ etc...

---

Quote:

---

Originally Posted by Ayreon

Wouldn't that mean that every time a function in one of the other .c files uses one of the variables, that it needs to call a function that creates this variable? That's exactly what I am trying to avoid. These variables are constant from the moment they are created, it makes no sense to reacalculate them every single time they are needed in a function.

---

No, it creates once then returns the value thereafter.

Quote:

---

Originally Posted by laserlight

No, it creates once then returns the value thereafter.

---

Then where does this value go, so that all other files can see it?

Quote:

---

Originally Posted by Ayreon

Then where does this value go, so that all other files can see it?

---

Well...

Quote:

---

Originally Posted by anduril462

Make the variable a static global in one .c file, so no other files can see it. Provide a set of functions in that .c for accessing and manipulating that variable, and only list the prototypes for those functions in the header.

---

So for example I would need a function that creates M, which is m1+m2, and also returns it. But then every time I call this function in stead of calling a global variable M, it would have to calculate M again. So this .c file would look like:

Code:

---

static M ;

double m1=1,m2=1 ;

double create_M(double m1,double m2){
  return m1+m2 ;
}

---

And that's where I get confused, I am not using M at all, so I still don't understand what you mean.

The basic idea can be expressed along these lines:

Code:

---

static double M;

double some_expensive_function(void);

double get_M(void) {
    if (M == 0) {
        M = some_expensive_function();
    }
    return M;
}

---

Wait, does OP need a function to create the variable? I thought we were doing
header:

Code:

---

extern double phys_MO;

---

one C file:

Code:

---

double phys_MO = 4.29496E-6;

---

(OP: Note how the header should look.)

(EDIT: Oh, I see, we're trying to delete globals. Right.)

@Laserlight: I tried this and it seems to work. I just got in trouble now with one of the variables which is an array.
@tabstop: Tried this too, but must have had problems somewhere else for it did not work either.

In the mean time I've spoken to someone and he suggested to use a structure. From the sound of what he told me, this is going to be the best approach and also avoids use of globals and what not.

My intention was to "tidy up" my code, trying to avoid functions with a huge load of arguments, and preventing certain variables from being calculated over and over again. The structure method seems to be able to reduce the list of arguments in a function to just this structure itself and I only have to change the members of the structure once, all the way at the beginning of the program.
So that's what I am trying to implement now.