|
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
|
|
|
|
|
this is not what i'd call a OO solution, though
|
|
|
|
|
Of course. I'm here just for that.
You don't recall our agreement:
You give OO solutions.
I give the (OOP) misleading ones.
Do you?
BTW I agree with Nemanja Trifunovic:"static member variables are also really globals, no matter how you call them". Static member variables are dressed up globals.
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
|
|
|
|
|
but I got a vote '3' for preventing a newbie to use global variables ?! 
|
|
|
|
|
My friend you worry too much about votes. Anyway you got my five to balance a bit.
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
|
|
|
|
|
there some code like:
int a[] = {1,2,3,4,5};
int* ptr = (int*)(&a+1);
printf("%d\n",*(ptr-1));
i know,the name of a array(here is a) is a const point. So,&a should be a point of a,its type should be int**. But,why ptr-1 point the last element of the array?It seems a little strange!
Regards.
|
|
|
|
|
A few weeks ago we had a q&a with g_g about this.
Someone (I think David Crow) pointed out that the pointer to an array is the array itself.
Odd, but true.
int a [] = {1,2,3,4,5};
int *p;
p = a;
&a is a int [] still, but &p is an int **.
It is is bizarre, but an early example of a compatibility hack, to help things like scanf, printf, etc.
While I may not be putting this perfectly well, just accept this is a rare quirk of C, shrug and move on.
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
but i still puzzled why &a remains to be a int[]?
of course a do is,but why &a?
|
|
|
|
|
See also here [^].
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
|
|
|
|
|
yeah.that says a == &a is true.
but why the out put will 5?
maybe in &a+1,it treat the array as one variable,so &a+1 will jump the entire array to the end of the array? if right,all the thing become easy,i will understand too.
Thanks
|
|
|
|
|
kcynic wrote: but why the out put will 5?
because of pointer arimethic: sizeof(a)== 5 * sizeof(int), hence &a+1 == ((int*)&a)+5.
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
|
|
|
|
|
I see it now.Thanks very much.
|
|
|
|
|
kcynic wrote: int a[] = {1,2,3,4,5};
int* ptr = (int*)(&a+1);
kcynic wrote: So,&a should be a point of a,its type should be int**.
no, &a is of type int (*)[5], not int **. Othercase is Don't think int ** and int [][], multi dimensional array are same the former stores pointer to some different location while later stores in values in contigious location.
kcynic wrote: But,why ptr-1 point the last element of the array?
so, &a is of type int (*)[5], (not int **), so incrementing a pointer increments based on the type, so (&a + 1) actually points next to the enter size of array; since that is the type, int (*) [5].
so ptr - 1 points to last element.
i repeat int (*)[5] is not same as int **, you can ensure this by trying the following code,
int *ptr = (int *)(((int **)&a) + 1);
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
