It a program just like an operating system there is no difference.Originally Posted by laserlight
It just performs a different function thats all.
Like many programs it is designed badly.
Very badly indeed, why for example is the edit box not as wide as the display screen?
It's an absolute pigs ear.
I agree with laserlight 100%.
I've been writing C programs professionally for over 10 years now and it has been my experience that the more global variables a program has the more likely it will have hidden bugs and eventually cause errors in data or just plain bomb if the OS or database changes.
Since it sounds like you are the sole maintainer of the code, globals may be fine for you, but when you work in a shop where several different coders can work on the same bit of code, globals can make maintainability a nightmare.
It's not the first time esbo has got us into a long and pointless discussion of the practices that he considers fine.
It's all just loads of non-sense.
For example, when he talks about the ease of tracking the global variable in every function with search tools, he doesn't take into account that it is not enough to see where a variable is used but also what has happened before and what is going to happen afterwards. When you want to understand what's going on you also need to track the program flow in the scope where the variable is alive, so that would be ... virtually in the entire code-base.
Compare that to tracking the program flow around the limited lifetime of a local variable. As to tracking the variable when passed to other functions under a "different name" then is it really the "same" variable in those other functions? Or do you really need to track down the whole execution flow to understand what's going on with one variable if you know what the function is supposed to do (but not all implementation details, of course)? Do you ever feel the need to "track down" the char pointer that you passed to strlen? What esbo fails to understand is that there might be advantages in making user-defined functions similar to standard library functions in this respect.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
Well the more of anything a program has the more likely it will have bugs.
More oppertunity to make errors.
I find the easiest way is to search on a variable, then I can easilly see what it affects.
It does not help if I have to track dozens of different variables, for a start I have
to remember what they are called.
I don't thnk the number of coders makes any difference, the search function does not care
if it was one or a million, if fact I don't think it even knows.
A variable can have all sorts of effects changing other variables and program control.
You can write bad code using any technique.
Getting rid of globals for the sake of it is as bad as using all globals for the sake of it, you can get both practices.
Anyway unless you can actually prove soomething it's all really a load of hot air isn't it?
I have not seen a proof yet. Saying Professor Loco (or whatever) says it is a good idea.
proves nothing.
No proof no coconut.
It's not the first time I have had my views dismmissed and nonsense pointless etc without any proof.
It is easy to see what happens before and after when you search on a variable.
The real 'scope' of a variable, is how it affects the overall program, you can't change
that with local variables.
Put it this was I track one variable and you have to track 10 local ones.
Which is easier, OK my 1 might interact 10 times but the net result is he same.
It's like a jig-saw, you have lots of little pieces I have one big picture.
I use functions when necessary, no more no less.
Any as I have said before without a proof it's just hot air, futhermore it's not entirely
clear what anyone is talking about. It is a program which merely exists in your imagination (or mine).
Basically we are writing code for an undefined program so "don't use a global variable here" is as valid as "do use a global variable here".
As for pointless discussions, it takes two to tango.
I don't think the problem is so much that "globals are bad" but that you consistently use them for a purpose which they are not intended, and pimp yourself. In particular, any program data is a global definition in your crippled approach, almost every time, and that's whatworks, period. You're consistently ignoring the points people are making in this thread, so the "discussion" is rather tiresome. We're simply not communicating. For that reason I think the thread should be locked and we can all move on.
If you're derision towards teaching was a direct result of my earlier posts, I'm sorry for assuming you were interested in learning anything from anyone, and I'm sorry for suggesting that you defer to someone else for a more detailed explanation than the one I gave you. It came with examples, so I thought that would help you understand. If you would simply listen to others now and then instead of demanding "proof" for this or that, then you might learn something.
It confuses me, your insistence, because you can only prove logic. Abstraction (which is what we're discussing) is a technique. You cannot prove a technique. If you learn a technique, you can determine where it is applicable. If you use a technique, then you can weigh its value and finally have an educated opinion. You would have a reason for not liking it other than it's not what you normally do.
To tie in with your conclusion I think you are under the coconut effect. There are better ways to program, but you just don't identify it as such, so you keep doing it your way because that's the only way you can say it works. That's all you ever knew! You can't be held responsible for your ignorance.
Last edited by whiteflags; 12-18-2008 at 09:26 PM.
I think that is a great analogy. Those who start with the little pieces, especially the corners and the sides, finish the jigsaw puzzle faster than those who attempt to finish it all at once, if the latter ever succeed at all
They still have the big picture since it is laid out on the box cover (i.e., the formal specifications and overall system and component design).
That would be true if we were indeed "writing code for an undefined program". However, we are not writing code, but talking about general principles, in response to Tibor's general question.Basically we are writing code for an undefined program so "don't use a global variable here" is as valid as "do use a global variable here".
Look up a C++ Reference and learn How To Ask Questions The Smart Way
