|
Did you get a job doing image processing on medical imagery??
|
|
|
|
|
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
|
|
|
|
|
ptr_Electron wrote: is there a better OO way
yes. use a public static member of a class...
|
|
|
|
|
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...).
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
|
|
|
|
|
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
|
|
|
|
|
Could you please post the relevant code (i.e. where variable is referenced, both declarations and definitions)?
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
|
|
|
|
|
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
|
|
|
|
|
[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.
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
modified on Friday, March 28, 2008 11:13 AM
|
|
|
|
|
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,
|
|
|
|
|
Can you tell me the reason you're always doing the exact opposite of what I suggested?
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
|
|
|
|
|
Well, I made it excatly what as you told, but the change did not refelected in the other file
and I made static,
|
|
|
|
|
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.
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
|
|
|
|
|
It worked,,, thank you
|
|
|
|
|
ptr_Electron wrote: It worked
Finally!
ptr_Electron wrote: thank you
You're welcome.
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
|
|
|
|
|
CPallini wrote: IMHO global varibles are not evil
IMHO they are, unless they are constants
|
|
|
|
|
Well, the overall size of the project has a role in.
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
|
|
|
|
|
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 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
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
And one very important note: static member variables are also really globals, no matter how you call them.
|
|
|
|
|
Of course all non const globals should in fact be data hiding objects that are inherently thread safe but you already knew that. 
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. 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
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.
|
|
|
|
|
Nemanja Trifunovic wrote: And one very important note: static member variables are also really globals, no matter how you call them
Yes, but there are less chances of name clashes with them.
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
|
|
|
|
|
CPallini wrote: Yes, but there are less chances of name clashes with them.
True. Although I prefer using namespaces to avoid name clashes.
|
|
|
|
|
Actually universe isn't such stable...oops, wait a minute, what software are you talking about?
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
|
|
|
|
|
How many times has the value of PI or C or 2^31 or the ASCII char for 'b' changed since you started programming?
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
PI precision changes continuosly. 2^31 is a number, i.e. a human brain construct hence it doesn't exist in the universe, c invariance is a rather new concept, ASCII codes, being a mere agreement, have nothing to do with universe.
The universe itself is quickly changing, probably even forgetting about c invariance.
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
