C / C++ / MFC

28-Mar-08 2:32

I had two cpp file, there i one common .h included file to both of them. appart from their respective .h files
so I declard a variable in the common .h file, so that I can access it from the both the cpp files..

is there a better OO way

toxcct28-Mar-08 3:01

toxcct

28-Mar-08 3:01

ptr_Electron wrote:
is there a better OO way

yes. use a public static member of a class...

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

CPallini28-Mar-08 3:12

28-Mar-08 3:12

If you wish to use a global variable the correct way is.
1. Define it in one of your source (*.cpp) files.
2. Declare it as extern in the other source files.

for instance:

file foo1.cpp

int iGlobal;

file foo2.cpp, foo3.cpp, foo4.cpp, ...
(alternatively you may include the following declaration inside a header file, included by all the above sources)

extern int iGlobal;

IMHO global varibles are not evil, anyway you should use it sparingly. OOP offers some techniques to avoid typical global variables issues (like name clashes, arbitray access...).
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

ptr_Electron28-Mar-08 3:54

28-Mar-08 3:54

Thanks for your responce, but it just flashes following...

warning LNK4006: "int ::nFuncEqu" (?nFuncEqu@ @@3HA) already defined in stdafx.obj; second definition ignored

and

error LNK2005: "int ::nFuncEqu" (?nFuncEqu@ @@3HA) already defined in StdAfx.obj

CPallini28-Mar-08 4:02

28-Mar-08 4:02

Could you please post the relevant code (i.e. where variable is referenced, both declarations and definitions)?

ptr_Electron28-Mar-08 4:08

Re: access variable from another file [modified]

28-Mar-08 4:08

mainly used .h file included in most of the files
int nFuncEqu;

using File1 // modiying the value in this file
extern int nFuncEqu;

using File2 // using the value in this file
extern int nFuncEqu;

All the abov things are not with in any class

CPallini28-Mar-08 4:21

28-Mar-08 4:21

[added]
here [^] it is explained very well.
[/added]

ptr_Electron wrote:
mainly used .h file included in most of the files
int nFuncEqu;

change to

extern int nFuncEqu;

ptr_Electron wrote:
using File1 // modiying the value in this file
extern int nFuncEqu;

change to:

int nFuncEqu;

(and you don't need to include the header file there).

ptr_Electron wrote:
using File2 // using the value in this file
extern int nFuncEqu;

if you include the header file then remove the declaration. On the other hand, if you don't include the header file, leave the declaration as it stands.

The rule for extern declarations is:

you must declare your variable as int nFuncEqu only inside one source file (i.e. .cpp) while declaring it extern int nFuncEqu in all other source files. Including the header (containing extern int nFuncEqu) is simply a shortcut for all those extern declarations.
Smile | :)

modified on Friday, March 28, 2008 11:13 AM

ptr_Electron28-Mar-08 5:38

28-Mar-08 5:38

I made it as static, it is compiling , i modified the value form one file, and it was not reflecting when I am accessing if from the other file, it was not modified inbetween… it remains zero,

CPallini28-Mar-08 5:45

28-Mar-08 5:45

Can you tell me the reason you're always doing the exact opposite of what I suggested?

ptr_Electron28-Mar-08 6:12

28-Mar-08 6:12

Well, I made it excatly what as you told, but the change did not refelected in the other file
and I made static,

CPallini28-Mar-08 6:22

28-Mar-08 6:22

Don't make it static.
Other people suggested to make it static member of a class, not to do a static variable declaration. Static variable declaration make the variable itself having file-scope, i.e. it is visible only inside the file wherein it was declared.
I repeat, if you want to use a global variable:
(1) declare it inside you header file as extern int.
(2) declare it inside one source file as int.
(3) include the header file inside all source files.
Hope that helps.
Smile | :)

ptr_Electron1-Apr-08 22:42

1-Apr-08 22:42

It worked,,, thank you Smile | :)

CPallini1-Apr-08 23:04

1-Apr-08 23:04

ptr_Electron wrote:
It worked

Finally!

ptr_Electron wrote:
thank you

You're welcome.
Smile | :)

Nemanja Trifunovic28-Mar-08 4:15

Nemanja Trifunovic

28-Mar-08 4:15

CPallini wrote:
IMHO global varibles are not evil

IMHO they are, unless they are constants Smile | :)

Programming Blog

utf8-cpp

CPallini28-Mar-08 4:23

28-Mar-08 4:23

Well, the overall size of the project has a role in.
Smile | :)

Matthew Faithfull28-Mar-08 4:50

Matthew Faithfull

28-Mar-08 4:50

IMHO it has little to do with const-ness, much more to do with the question.
Is what is it represents really and justifiably process global?
Because you can only very seldom honestly answer yes to that question, e.g. definition of stdout or value of WIN_VER then you shouldn't have many globals. Most of them will probably end up being constants but that's just down to the relatively stable nature of the universe in relation to software lifecycles Big Grin | :-D

Nothing is exactly what it seems but everything with seems can be unpicked.

Nemanja Trifunovic28-Mar-08 5:03

Nemanja Trifunovic

28-Mar-08 5:03

Matthew Faithfull wrote:
IMHO it has little to do with const-ness

It has for the following two reasons:

1) Because any code can change a non-const global variable at any point, it is very hard to track its state, esp. during debugging.

2) Multithreading. 'nuff said Smile | :)

And one very important note: static member variables are also really globals, no matter how you call them.

Programming Blog

utf8-cpp

Matthew Faithfull28-Mar-08 5:20

Matthew Faithfull

28-Mar-08 5:20

Of course all non const globals should in fact be data hiding objects that are inherently thread safe but you already knew that. Smile | :)

Nemanja Trifunovic wrote:
And one very important note: static member variables are also really globals, no matter how you call them.

Not really, I used static instances of classes as private: members quite often and they can't really be said to be global because they can only be accessed from instances of the
particular class e.g.

class CSomething
{
    //...
    private:
    static CLock m_LockSomethings;
};

Even more commonly m_LockSomethings would be protected: so the lock can be used by derived classes and cover the whole hierarchy. You might consider this bad OO but you can't deny it's useful. Big Grin | :-D

Nothing is exactly what it seems but everything with seems can be unpicked.

Nemanja Trifunovic28-Mar-08 7:18

Nemanja Trifunovic

28-Mar-08 7:18

Matthew Faithfull wrote:
Of course all non const globals should in fact be data hiding objects that are inherently thread safe but you already knew that.

Even if they are thread-safe in the sense they are protected by locks, it can badly hurt the performance, but it really depends on the design - a queue may help, for instance.

Matthew Faithfull wrote:
I used static instances of classes as private: members quite often and they can't really be said to be global because they can only be accessed from instances of the
particular class

You're right, - I should have said "public static", instead of just "static". Private static are really similar to static variables at the file level in C.

Programming Blog

utf8-cpp

CPallini28-Mar-08 5:21