problem with declare global variable

[aeo3]

I need to define a global variable that many files will see it, this variable is a pointer to class. but i failed to do it.
I have a set of classes each in separated files

[RedSon]

What code do you have already? Declaring a class pointer should be as simple as ClassName *pMyClass;

[aeo3]

yeap, but i need all other files see it

[RedSon]

yeap, but i need all other files see it

If you declare something outside of any brackets it becomes global. If you want to use it in another file you will have to use the extern keyword. Or you can also declare it in a header and have both cpp files include that header.

[weaknessforcats]

Consider not using a global variable but using a Singleton object instead.

Read this.

[aeo3]

I have four files x.h, y.h, z.h and w.cpp
each _.h contains a class. i need for example x.h and z.h deal with a class that exists in z.h

[ravenspoint]

I have four files x.h, y.h, z.h and w.cpp
each _.h contains a class. i need for example x.h and z.h deal with a class that exists in z.h

Suppose you have a class T, whose interface is deined in file t.h

Create a global object of class T, outside of any brackets in your mainline file

#include "t.h"
 
T global_t;

Allow anyone who wants to see your global by adding to t.h the following line, near the end, outside any brackets

extern T global_t;

[aeo3]

but i need it as a pointer to that class when i tried to do, functions in other classfiles didnot see it.

[ravenspoint]

but i need it as a pointer to that class when i tried to do, functions in other classfiles didnot see it.

So? Make it a pointer then.

in mainline

T t;
 
T * global_ptr_T;

inside main()

global_ptr_T = &t;

in t.h

extern T* global_ptr_T;

[aeo3]

It works now ,
thank you

[weaknessforcats]

extern T* global_ptr_T;

Just be aware that the object may not have been created before you use the pointer. This is one of the cases against using global variables: The Initialization Fiasco:

MyClass  AnotherGlobalObject(global_ptr_T);
 

There really is no case where a global variable is required.

I say again, try using a Singleton object.

[ravenspoint]

Just be aware that the object may not have been created before you use the pointer.

Please look, carefully, at the first code fragment where I create the object before taking its address and assigning it to the global pointer.

No fiasco this time :-)

[ravenspoint]

MyClass  AnotherGlobalObject(global_ptr_T);
 

To fix this, write

MyClass  AnotherGlobalObject( &t );
 
 

[weaknessforcats]

Please look, carefully, at the first code fragment where I create the object before taking its address and assigning it to the global pointer.

That's not the issue. Your pointer is valid.

It's just in this other file:

extern extern T* global_ptr_T;
MyClass  AnotherGlobalObject(global_ptr_T);
 
int main()
{
 
}
 

that the global pointer may not be valid. There is no guarantee as to the order which .cpp files get initialized.

[ravenspoint]

That's not the issue. Your pointer is valid.

It's just in this other file:

extern extern T* global_ptr_T;
MyClass  AnotherGlobalObject(global_ptr_T);
 
int main()
{
 
}
 

that the global pointer may not be valid. There is no guarantee as to the order which .cpp files get initialized.

This would not compile - you would have two files containing main().

Perhaps I should have emphasized more strongly that all globals should be declared in the file that contains main(), between the includes and the Main() entry point. In this way we have control over the initialization order.

Yes, if you sprinkle global declaration all over the place, chaos will be the result.

Also, I do agree with you that globals should be avoided wherever reasonable. I like to use the phrase "polluting the global namespace" to motivate myself to take the trouble to avoid them. However, in the the real world of quick and dirty programs to solve today's problem, using a few globals can save an amount of design work that is inappropriate to the task at hand.

[weaknessforcats]

Perhaps I should have emphasized more strongly that all globals should be declared in the file that contains main(), between the includes and the Main() entry point. In this way we have control over the initialization order.

Yes. But this has the restriction that you can't use these globals in another program without carrying main() along. So you have top make a copy and maintain duplicated code.

The globals do need to be in one place and it is not the file with main() in it. It is another .cpp file. These globals should be in an anonymous namespace accsssed by a Singleton object. That way you can reuse the globals in many programs.

On a broader note, globals are not good for these reasons:
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 the 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. Bad if there is a large installed base.

[ravenspoint]

Yes. But this has the restriction that you can't use these globals in another program without carrying main() along. So you have top make a copy and maintain duplicated code.

I am sorry, I do not understand this point. Why would you want to use the same globals in another program? What would it mean if you did? In any case, I am fairly sure the OP did not want to do any such thing, he just wanted to get his program working ( which he did ) and perhaps get some advice on how to avoid such problems in future

On a broader note, globals are not good for these reasons:

I have already agreed, globals are not good. You are beating a dead horse.