About using global vars

Printable View

12-12-2008
Tibor

About using global vars

I read that global variables are not advised, so I have tried to use them the less I can, but there are always a few of them I need. Because I need speed code, I have the following question about global variables:

1) Why are they not advised?
2) Although I use they the less I can, what guidelines can I follow to use they in the best and efficient way?
3) Does using the 'restrict' keyword when declaring the var be good in order to get faster global variable management code.
4) Does has any sense to declare a global variable with the 'register' keyword?
5) I have read global vars are reloaded after a function call. Is there anyway this can avoided (when we now for sure that the called function does not modify that var)?

Thanks
12-12-2008
laserlight

We covered your first question recently in dark side of global variables.
12-12-2008
QuantumPete

Quote:

Originally Posted by Tibor

2) Although I use they the less I can, what guidelines can I follow to use they in the best and efficient way?

By not using them. Honestly, there is hardly any reason to use them. Most things can be accomplished by passing a pointer to a struct around.

QuantumPete
12-12-2008
zacs7

> By not using them. Honestly, there is hardly any reason to use them. Most things can be accomplished by passing a pointer to a struct around.
Not always, they have their place...
12-12-2008
hauzer

I agree with zacs. They are useful sometimes.
12-12-2008
QuantumPete

Quote:

Originally Posted by hauzer

I agree with zacs. They are useful sometimes.

Which is why i said "Hardly any reason" and "Most things" ;) In my opinion global variables are like using goto. It has it's place and can be useful, but for a beginner it's one of the most over-abused concepts.

QuantumPete
12-12-2008
C_ntua

3) As far as I understand you declare a variable restrict, I think only pointers, when you know FOR SURE that it is the only pointer that points at some data. So you can gain some optimizations. I haven't used it ever. Dunno how useful it is. But if you are not actually sure that it is a restrict, you will get undefined behaviour. So it is not recommended.
4) Well, as a standard rule DON'T use the register keyword. Except if you really know what you are doing. You just have to know that the compiler does this for you. It registers some variables in CPU registers in order to gain optimized code. How is not that simple.
Registering a variable to a CPU register means that you narrow down the choices the compiler has to do its optimization.
Generally the compile knows best and really does its job good (modern compilers at least). But I am sure there are some occasions that the user knows better, but those are rare.

5) Reloaded in what sense?

Generally, don't use restrict and/or register keywords

1) All give you some quick ones
* If not necessary don't use them. Meaning that if you can use local variables do so
* Use really good names for global variables. If you want you can add a g_ in front of them just to tell people the variable is global.
* If a function has 1 or two arguments and uses a global variable, maybe you should consider passing the variable by pointer and making it local in main.
* If you modify 2-3 variables together, you can again make a struct and pass it by pointer to the function so you avoid global variables.
* Use good names. No "x", "y".
* Oh, and don't forget to use good names. Like "boardX", "boardY" for the coordinates of a board rather than "X", "Y".
* If you actually use global variables a lot, consider giving them nice and readable names

edit: Sorry for my grammar and syntax errors. Even more sorry for being (as always) bored to fix them :)
12-12-2008
matsp

In a previous discussion about global variables and registers, the global register option (which by the way is not supported by the C standard - it is a gcc extension to allow this) did not only produce obviously worse code, but in some variants of the compilation, it even crashed the code (most likely because it is rarely used and some compiler bugs exist in this area). On a 32-bit x86 processor, there are SO FEW registers even without locking one down for a global variable, that the compiler is bound to make better use of the registers (unless of course you only have like three varaibles in your code, and you use this global variable in many places in many small functions). Some processors have many more registers so the penalty for locking a register to hold a global variable may be smaller - but it's still unlikely to give you any huge advantage except in very special circumstances.

Yes, in general, global variables are reloaded after function calls. There is very little you can do to prevent this, as the compiler has no idea whether some global variable was modified by the called function or not unless it can see all of the called code itself and detemine for sure that there is no possibility that the code changes a particular (set of) global variable(s).

This is the "you get bad performance from global variables" problem - there are other problems with global variables, but the "reload after calls" is definitely a performance (and potentially code-size) problem.

--
Mats
12-12-2008
C_ntua

Does the compiler perform any optimization on this? Like check if the global variable is even used in the function?
12-12-2008
matsp

Quote:

Originally Posted by C_ntua

Does the compiler perform any optimization on this? Like check if the global variable is even used in the function?

It may do, but if it wants to use the register for another reason it will then have to SAVE the register and restore it again when it returns from the function (but then it probably would have to do that anyways, as you can only use "preserve" type registers for register globals - if you use one of the "these get destroyed when you call another function", any call to a C library function which isn't compiled specifically to know about the global would possibly destroy the global register content).

--
Mats
12-12-2008
esbo

Quote:

Originally Posted by Tibor

I read that global variables are not advised, so I have tried to use them the less I can, but there are always a few of them I need. Because I need speed code, I have the following question about global variables:

1) Why are they not advised?
2) Although I use they the less I can, what guidelines can I follow to use they in the best and efficient way?
3) Does using the 'restrict' keyword when declaring the var be good in order to get faster global variable management code.
4) Does has any sense to declare a global variable with the 'register' keyword?
5) I have read global vars are reloaded after a function call. Is there anyway this can avoided (when we now for sure that the called function does not modify that var)?

Thanks

They are not advised by some people because they "don't like them" here are some reason I found:-

"a global variable can potentially be modified from anywhere"

Well some people would say that's a bad thing but of course it is quite a good thing if
you want to access them from anywhere isn't it!!

What was from wikipedia, the other reasons they gave seemed a bit more unclear to
me, words such as 'complexity' arose, butif something is complex, well it is gonna be complex, there is not much you can do about that, maybe you can shift that complexity
from global variables to function calls and passing local variables but it is there nonetheless.

I think it is a question of getting the right amount of global variables not trying to reduce them for the sake of it.

But you can ask does the compiler or the microprocesser find global variables a problem?
Answer no!!

I normally just ask myself is this is a localised variable, because that is an easy question to answer.

However if you want to write a program to be as fast as possible global vaiables will do that for you.

I find most of the time it's fairly obvious what the scope of viable should be, but it is difficult to specify a general rule. I think it come down to will it be used often, do you know
exactly where it will be used? If you don't my default is global.

I find people who teach programming tend to waffle on about them endlessly, but unless you are talking about a specific program it is all rather meanngless ill defined waffle.
How long is a piece of string stuff. Or like telling someone how to ride a bicycle, you will soon pick it up once you fall over a few times. It's much easier to learn by doing something then listening to someone explain it. (I find).
12-12-2008
laserlight

Quote:

Originally Posted by esbo

Well some people would say that's a bad thing but of course it is quite a good thing if
you want to access them from anywhere isn't it!!

That is true, but such global objects should be rare in a well designed program. Note that global constants do not count here since they do not add state, hence it is easy to reason about them from anywhere in the program.

Quote:

Originally Posted by esbo

words such as 'complexity' arose, butif something is complex, well it is gonna be complex, there is not much you can do about that, maybe you can shift that complexity
from global variables to function calls and passing local variables but it is there nonetheless.

The idea is to manage the complexity by making it possible to reason about individual parts of the code.

Quote:

Originally Posted by esbo

I find most of the time it's fairly obvious what the scope of viable should be, but it is difficult to specify a general rule. I think it come down to will it be used often, do you know
exactly where it will be used? If you don't my default is global.

The correct default is to use local variables.
12-13-2008
esbo

Quote:

Originally Posted by laserlight

That is true, but such global objects should be rare in a well designed program. Note that global constants do not count here since they do not add state, hence it is easy to reason about them from anywhere in the program.

They should be as rare or as common as they need to be.

Quote:

Originally Posted by laserlight

The idea is to manage the complexity by making it possible to reason about individual parts of the code.

The program runs as a whole, reasoning about a small part cannot tell you the overall
effect.

Quote:

Originally Posted by laserlight

The correct default is to use local variables.

The only thing 'correct' about a program is whether it does what it is supposed to do.
You can have all your variables correctly scoped and it can still fall over in a heap, or just not do what you intened it to do. Any 'correctess' beyond that is rather academic and a matter of ill defined opinion.
If 'correctness' is something dreamt up by a third party, well that's a different matter, it depends who the third party is, if the third party is is me it is just whether the program does what it is supposed to do, no more no less. If it is you well you might require futher constraints.
12-13-2008
laserlight

Quote:

Originally Posted by esbo

They should be as rare or as common as they need to be.

The reasons why global variables need to be as rare as possible (or more accurately, as rare as feasible, since it is always possible to do without them, but it may not be practical to do without them) have already been cited.

Quote:

Originally Posted by esbo

The program runs as a whole, reasoning about a small part cannot tell you the overall
effect.

Obviously. However, reasoning about small parts can help you reason about the program as a whole. You can liken this to proving a series of lemmas in order to prove a theorem (and in fact it is literally the case in formal verification of program correctness).

Quote:

Originally Posted by esbo

You can have all your variables correctly scoped and it can still fall over in a heap, or just not do what you intened it to do.

That is true. You can also have all your variables poorly scoped "and it can still fall over in a heap, or just not do what you intened it to do". In other words, that good development practices do not guarantee correct programs does not mean that they should not be practiced. Poor development practices, such as the unnecessary use of global variables, merely make program correctness less likely.
12-13-2008
esbo

I find it easy to track the effect of a vairable in a progran simply my seaching on it in an editor. That is dead easy with a global variable, however when data is pass the name usually changes. This makes it much more difficult to follow like 10 times more difficult.

The over use of local variable can make a program an absolute nightmare to follow.
I have see it my self, the same variable changing names half a dozen times, it makes
the program very difficult to follow.
12-13-2008
tabstop

Quote:

Originally Posted by esbo

I find it easy to track the effect of a vairable in a progran simply my seaching on it in an editor. That is dead easy with a global variable, however when data is pass the name usually changes. This makes it much more difficult to follow like 10 times more difficult.

The over use of local variable can make a program an absolute nightmare to follow.
I have see it my self, the same variable changing names half a dozen times, it makes
the program very difficult to follow.

Do you not ever call your functions with different input? And for that matter, since functions can't change the value of the parameters passed into them, that's irrelevant for tracing purposes anyway.
12-13-2008
esbo

Quote:

Originally Posted by tabstop

Do you not ever call your functions with different input? And for that matter, since functions can't change the value of the parameters passed into them, that's irrelevant for tracing purposes anyway.

Yes I do call functions sometimes when appropiate but I have see programs which have be 'over engineered' into a mess because of an over empathsis on local variables.

But the values passed into the function affect how the programs runs.
It is simple to see what the effect of a variable is on a program by searching on it
in an editor, however once it disappears into a function it 'disappears'.

Most of the programs I have seen have been 'ruined' by 'good programming practise'
in my opinion. The programmers lose all sense of proportion dogmatically following 'rules'.
12-13-2008
King Mir

Quote:

Originally Posted by esbo

But the values passed into the function affect how the programs runs.
It is simple to see what the effect of a variable is on a program by searching on it
in an editor, however once it disappears into a function it 'disappears'.

Yes, but you shouldn't need to look through code to see what a variable is supposed to do. The name, documentation, and general project design should make it clear what each variable does.

If there is a bug, the problem is not with the variable, its with some function that doesn't do what its supposed to do. And functions are a lot easier to debug when you know by looking at the prototype what they can do and what they might change.
12-13-2008
King Mir

Quote:

Originally Posted by esbo

I find it easy to track the effect of a vairable in a progran simply my seaching on it in an editor. That is dead easy with a global variable, however when data is pass the name usually changes. This makes it much more difficult to follow like 10 times more difficult.

The over use of local variable can make a program an absolute nightmare to follow.
I have see it my self, the same variable changing names half a dozen times, it makes
the program very difficult to follow.

Have you tried using a debugger trace? It has the advantage of showing you what order a variable is used in, which can be much more useful than an editor search or a grep in showing program flow.
12-13-2008
whiteflags

Quote:

Originally Posted by esbo

It is simple to see what the effect of a variable is on a program by searching on it
in an editor, however once it disappears into a function it 'disappears'.

Or someone, besides you, could name their local variable the same as you named some global variable, and then the global 'disappears'. In C, local identifiers have precedence over a name with a wider scope.

If you don't want to rename a variable several times, then don't, that's your prerogative. Why would you do that if you're working on projects alone anyway? That's not a reason to prefer globals.

As soon as you work on a team though, abstraction becomes important so several people can build the software together, without breaking each others code inadvertantly, like through a naming clash, or by wanton use of some unrestricted value. That's really why lots of languages have some idea of scope in the first place.
12-14-2008
esbo

Quote:

Originally Posted by King Mir

Yes, but you shouldn't need to look through code to see what a variable is supposed to do. The name, documentation, and general project design should make it clear what each variable does.

If there is a bug, the problem is not with the variable, its with some function that doesn't do what its supposed to do. And functions are a lot easier to debug when you know by looking at the prototype what they can do and what they might change.

Are you serious? "The name, documentation, and general project design should make it clear what each variable does. ".
The variable does what it does, the documention etc is what is 'supposed' to do.

What if there is no documentation?

Most variable are not documented.
The only thing which will tell you what a function does is the code.
There may be errors in the design at all levels.
12-14-2008
esbo

Quote:

Originally Posted by King Mir

Have you tried using a debugger trace? It has the advantage of showing you what order a variable is used in, which can be much more useful than an editor search or a grep in showing program flow.

There may not be a debugger aavailable.
What a 'trace' is is unclearly defined, there may well not be one which does what you
just described, if indeed at all of if I even understand what you mean. (unclear).
12-14-2008
esbo

Quote:

Originally Posted by whiteflags

Or someone, besides you, could name their local variable the same as you named some global variable, and then the global 'disappears'. In C, local identifiers have precedence over a name with a wider scope.

I have never really ecountered that as a problem, people don't usually give different variables the same name in a waay which would cause confusion.
12-14-2008
whiteflags

Quote:

I have never really ecountered that as a problem, people don't usually give different variables the same name in a waay which would cause confusion.

Well thanks for your opinion, but that is a serious drawback that you can't just ignore with some amount of hand-waiving (which seems to be what you're offering in general). What if the variable represents the same value (a function parameter, for instance, versus the argument)?

Or in the context of my argument, you simply name the global poorly, and someone else names a different variable the same, but with a more restricted scope?

Whatever else you could think of... Local variables make this a non-issue.
12-14-2008
esbo

Quote:

Originally Posted by whiteflags

As soon as you work on a team though, abstraction becomes important so several people can build the software together, without breaking each others code inadvertantly, like through a naming clash, or by wanton use of some unrestricted value. That's really why lots of languages have some idea of scope in the first place.

I have worked on on a team and not encoutered such problems, I am not even sure what you are talking about in 'abstractation' it's unclear.
Your reasons are very wooly and unclear, "wanton use of some unrestricted value"?
what the heck does that mean?

Yes variables have a scope some global some local, it's a choice you do't have to try and
make all the variables local, as some people do.
12-14-2008
esbo

Quote:

Originally Posted by whiteflags

Well thanks for your opinion, but that is a serious drawback that you can't just ignore with some amount of hand-waiving (which seems to be what you're offering in general). What if the variable represents the same value (a function parameter, for instance, versus the argument)?

Or in the context of my argument, you simply name the global poorly, and someone else names a different variable the same, but with a more restricted scope?

Whatever else you could think of... Local variables make this a non-issue.

I'm not really sure what you are talking about.
Can you give an example?
It all sounds like an non-issue to me.
12-14-2008
whiteflags

Quote:

Originally Posted by esbo

I have worked on on a team and not encoutered such problems, I am not even sure what you are talking about in 'abstractation' it's unclear.
Your reasons are very wooly and unclear, "wanton use of some unrestricted value"?
what the heck does that mean?

Ah, I see. Well 'abstraction' is an engineering principle that is applicable to software. In engineering, the idea is that if you build something like a machine, but you document the interfaces it uses. Then another layman can use it. As long as you use the correct cables, then the machine will work (even if you connect it to another machine!) without the person understanding how it works on the inside. That's a (rudimentary) definition of black box abstraction.

The same engineering principle is used in software design to allow programmers to work on big projects without necessarily keeping the entire project in their head at once. In the context of C it has to do with how you design your functions, which would be essentially subprograms, with their own inputs and outputs. Since most functions will accept data, churn on it for a while and then make results, it helps to write those things down somewhere, so you can maintain the program (assuming you write anything useful enough to last a long time). I invite you to attend a virtual lecture for the book, The Structure and Interpretation of Computer Programs, if you don't want to hear it from me.

If you do this as a way of life, then yeah, it's important. You can't work on commercial software without being at least a little organized, because the process is bigger than one person. And yeah, when people learn to program in school, good courses are designed to teach and have students practice these things, apart from rote memorization of language syntax.

Or, if your functions don't return any specific data, then you would document (with comments if there is no formal paper) the inputs of the function; the state it leaves things it worked on; maybe a few example figures to demonstrate the process. These things are all helpful when you return to the program to maintain it, long after you've forgotten its impleentation details. In the same way, it helps others understand your design decisions and how the program works.

Quote:

wanton use of some unrestricted value

You and I are working on a program together. You defined a global string to store input.
In an uncharacteristic blunder this variable is
char buffer[2048];

I decide that I need my own buffer for whatever purpose. Perhaps I'm doing some parsing and need to maintain parts of the input. So I write a function. In it, I also name a variable buffer, and now the global is hidden from the scope of that function.

Never underestimate how several people can lower the average IQ in a room. :)
12-14-2008
esbo

All you really need to know are which variables are external to your code.
These the variables which will interface to your code.
If you were using such a buffer it would usually be given a sensible name eg global_buffer.

You would probably have to declare it external to your code. It's not likely to be an issue.
12-14-2008
whiteflags

Well frankly I'm not going to search for the one pathological case that will get you to agree with me. Even if you disagree, it is the way it is. It sounds like to me that you cannot accept what you prefer is rather against the grain, especially since the language you use relies on scope to understand what an identifier means and it's type (well, at least when the compiler looks for a declaration).

Given your bias, you would do yourself a service to reach for an early version of BASIC whenever you need to write something
12-14-2008
esbo

Quote:

Originally Posted by whiteflags

Well frankly I'm not going to search for the one pathological case that will get you to agree with me. Even if you disagree, it is the way it is. It sounds like to me that you cannot accept what you prefer is rather against the grain, especially since the language you use relies on scope to understand what an identifier means and it's type (well, at least when the compiler looks for a declaration).

Given your bias, you would do yourself a service to reach for an early version of BASIC whenever you need to write something

It is really not a problem for me at all.
It might be for everyone else but that's their problem not mine.
I can easilly write code to fit into a big project.
If there are any scoping problems they will be easy enough to sort out.
It's not something I would want to waste time on beforehand.
12-14-2008
King Mir

Quote:

Originally Posted by esbo

Are you serious? "The name, documentation, and general project design should make it clear what each variable does. ".
The variable does what it does, the documention etc is what is 'supposed' to do.

What if there is no documentation?

Most variable are not documented.
The only thing which will tell you what a function does is the code.
There may be errors in the design at all levels.

Most variables are not documented because you can tell what they do given their name and the function they are in. If that isn't enough, then a comment is required. If the variable is part of the external API of the component, then more documentation is needed.

If you want to find out what something is supposed to do, you look at the documentation, the name, and the context.

If you are trying to find a bug, then you are correct that the documentation usually won't show it (unless the bug is in the design).

Quote:

Originally Posted by esbo

There may not be a debugger aavailable.
What a 'trace' is is unclearly defined, there may well not be one which does what you
just described, if indeed at all of if I even understand what you mean. (unclear).

Tracing is when a debugger steps through your code line by line as your program runs. It is an extremely common feature.

Certainly there are environments where you cannot use a debugger, and you are forced to examine code manually. Even then it is often most useful to follow code flow, rather than what variable is changing.

This benefit of semi-isolating when a variable changes is small compared to the other benifits of local variables (mentioned in the other thread). Indeed in most cases having function local variables is itself a way of isolating when a variable changes, as then you know that the variable can only change within the function it is declared in, and the functions called by it.
12-14-2008
King Mir

Quote:

Originally Posted by esbo

It is really not a problem for me at all.
It might be for everyone else but that's their problem not mine.
I can easilly write code to fit into a big project.
If there are any scoping problems they will be easy enough to sort out.
It's not something I would want to waste time on beforehand.

If it's everyone else problem and not yours then perhalps you have not worked on enough of such projects. In which case you should follow the design pattern, before you run into the problem that it solves on your own.
12-14-2008
esbo

I prefer to write code rather than talking about it.
That way once it is written at least everyone knows exactly what they are talking about, rather
than some ill defined definitions.

Lecturers like to talk about it first because otherwise you would have no homework :)
12-14-2008
King Mir

huh?

If you write code without formal design, then you wind up with crappy design. At least for big projects.
12-14-2008
esbo

Quote:

Originally Posted by King Mir

huh?

If you write code without formal design, then you wind up with crappy design. At least for big projects.

Ever noticed how most big formally designed projects end up having to be scrapped :)
12-14-2008
King Mir

Quote:

Originally Posted by esbo

Ever noticed how most big formally designed projects end up having to be scrapped :)

There are plenty of successful large software projects out there. I'd wager all of them had a formal design phase.

But what does that have to do with global variables?
12-14-2008
whiteflags

Quote:

But what does that have to do with global variables?

My attempt to explain how abstraction often makes globals unnecessary, and how they can actually break a program by introducing side effects has obviously failed entirely as opposed to just esbo's special case. :(
12-14-2008
laserlight

Quote:

Originally Posted by esbo

I can easilly write code to fit into a big project.

Define "big project".

Quote:

Originally Posted by esbo

I prefer to write code rather than talking about it.

Me too.

Quote:

Originally Posted by esbo

That way once it is written at least everyone knows exactly what they are talking about, rather
than some ill defined definitions.

Unfortunately, real world projects do not work that way. Even if you do not go with a full formal design up front, you still need to talk first and get the requirements right, otherwise you could all end up knowing exactly what you are talking about, except that what you are talking about is nothing like what the customer wanted.
12-14-2008
esbo

Quote:

Originally Posted by whiteflags

My attempt to explain how abstraction often makes globals unnecessary, and how they can actually break a program by introducing side effects has obviously failed entirely as opposed to just esbo's special case. :(

You realy can't talk in general terms about programs as they are all different.
Programs tend to have a fair bit of global data but then ever program is different.
The only thing which can break a program is the person(s) who write it.
Anyway it's all rather too vague, nobody knows what anyone else is talkin about because
we are talking about the undefined.
We can waffle on endlessly about the underfined but it is all rather pointless, unless we are
talking about something specific nothing has any real meaning.
It's all just too vague.
12-14-2008
laserlight

Quote:

Originally Posted by esbo

You realy can't take in general terms about programs as they are all different.

That's rubbish. Programs are different, but they have common characteristics in their requirements, design, development and maintenance (though these may differ depending on the exact area of computing).
12-15-2008
whiteflags

Quote:

Originally Posted by esbo

You realy can't talk in general terms about programs as they are all different.
Programs tend to have a fair bit of global data but then ever program is different.
The only thing which can break a program is the person(s) who write it.
Anyway it's all rather too vague, nobody knows what anyone else is talkin about because
we are talking about the undefined.
We can waffle on endlessly about the underfined but it is all rather pointless, unless we are
talking about something specific nothing has any real meaning.
It's all just too vague.

The extent of thought you've spent on a subject you so deeply care about is astonishing.
12-15-2008
robwhit

> I prefer to write code rather than talking about it.
> That way once it is written at least everyone knows exactly what they are talking about, rather
than some ill defined definitions.

> We can waffle on endlessly about the underfined but it is all rather pointless, unless we are
talking about something specific nothing has any real meaning.
> It's all just too vague.

You claim to have worked on projects before, and not using local variables is your style. Could you post or otherwise show a non-trivial example of a project that uses the techniques you are describing?
12-15-2008
King Mir

Quote:

Originally Posted by esbo

You realy can't talk in general terms about programs as they are all different.
Programs tend to have a fair bit of global data but then ever program is different.
The only thing which can break a program is the person(s) who write it.
Anyway it's all rather too vague, nobody knows what anyone else is talkin about because
we are talking about the undefined.
We can waffle on endlessly about the underfined but it is all rather pointless, unless we are
talking about something specific nothing has any real meaning.
It's all just too vague.

This seems a shrewd way to opt out of a discussion. First you make your point, then somebody else makes theirs, then you say that the subject is to broad an unconcrete to meaningfully talk about it in the first place.
12-16-2008
esbo

Quote:

Originally Posted by King Mir

This seems a shrewd way to opt out of a discussion. First you make your point, then somebody else makes theirs, then you say that the subject is to broad an unconcrete to meaningfully talk about it in the first place.

Because it is.
You can't prove global variables are bad.
If you can do it, do it, untill then stop making claims you cannot substanciate.
All you can give a lot of waffle basically.
I have a program with over a 100 globals and about 20 locals, it works fine.
It would have been much harder to write using al local variabes, although possible, why should I waste time doing that?
12-16-2008
esbo

Quote:

Originally Posted by robwhit

> I prefer to write code rather than talking about it.
> That way once it is written at least everyone knows exactly what they are talking about, rather
than some ill defined definitions.

> We can waffle on endlessly about the underfined but it is all rather pointless, unless we are
talking about something specific nothing has any real meaning.
> It's all just too vague.

You claim to have worked on projects before, and not using local variables is your style. Could you post or otherwise show a non-trivial example of a project that uses the techniques you are describing?

Not really.
I don't want my code stolen :)
What would it prove if I did?
I have a prog with over 100 global and about 30 local.
If I posted what would it prove?
I could post the code and the data it works on to prove that it works, then what are
you going to do?
Tell me it does not work????
Tell me I won't be able to modify or add to it?
Well I could post all the previous versions of it with less functionality which also work.

So what exactly are you going to say is bad about it????

Or maybe say it is only 1200 lines long and that I would have probllems if it was a million lines long?
The reason it is not a milion line long is because it is well written :)
12-16-2008
laserlight

Quote:

Originally Posted by esbo

You can't prove global variables are bad.
If you can do it, do it, untill then stop making claims you cannot substanciate.

The claims have been substantiated. You merely refuse to face the truth. "All you can give a lot of waffle basically."

In a way, you have a strawman argument, since it is indeed

Quote:

Originally Posted by esbo

I have a program with over a 100 globals and about 20 locals, it works fine.

Is it maintainable? Do you have a test suite? Are its components reusable with (almost) no modification?

Quote:

Originally Posted by esbo

It would have been much harder to write using al local variabes, although possible, why should I waste time doing that?

Clearly, this means that you lack the skill to participate in the development of programs of significant size.

Quote:

Originally Posted by esbo

Or maybe say it is only 1200 lines long and that I would have probllems if it was a million lines long?
The reason it is not a milion line long is because it is well written

No, the reason it is not a million lines long is because it is trivial.
12-16-2008
Brafil

In smaller projects, you shouldn't pass all-local variables. But in greater ones, you'll really mess things up. Look at namespaces. They're a great idea, but not used in C. Try organizing global structs.
12-16-2008
C_ntua

I think we need examples. Post some common examples like "here a lot use a global, but it could be avoided". Some users, I suspect many, don't have the experience in working for a big C project so all of this seems kind of undefined. I have only made 2 medium-small C projects (3-4K lines) and didn't find the need to use globals at all. I want to do something, I create a function that takes input and gives output. The data I pass all in a struct which I update and flags are again all in one struct that I pass (or could just have had one global variable, no big difference).
12-16-2008
matsp

Quote:

Originally Posted by C_ntua

I think we need examples. Post some common examples like "here a lot use a global, but it could be avoided". Some users, I suspect many, don't have the experience in working for a big C project so all of this seems kind of undefined. I have only made 2 medium-small C projects (3-4K lines) and didn't find the need to use globals at all. I want to do something, I create a function that takes input and gives output. The data I pass all in a struct which I update and flags are again all in one struct that I pass (or could just have had one global variable, no big difference).

All good points.

I would also like to point out that if a function takes more than three or four parameters and you think "Oh, well, if I make X a global, I don't have to pass it around so much" then it's most likely a scenario of "your funciton is trying to do too much". Of course, a parameter to a function CAN be a struct (or pointer to struct), which allows a grouping of several fields together into one variable. If you find that a lot of functions take the same set of variables, then passing them as a struct is one possibility.

--
Mats
12-16-2008
King Mir

Quote:

Originally Posted by esbo

Because it is.
You can't prove global variables are bad.
If you can do it, do it, untill then stop making claims you cannot substanciate.
All you can give a lot of waffle basically.

If you think that the use of globals is too case specific to talk about it, you should say that right of the bat.

I and most people here disagree, and think that there are meaningful statements that can be said about when you should use globals. Specifically, you should avoid using a global variables when the you can instead you a local variable passed as a parameter. Now this is a generalization, and there are perhalps borderline cases, where globals are preferred even though using a parameter is possible. Therefor an exhaustive proof is not called for, and the provided list of disadvantages (mostly from the other thread) is sufficent.

Quote:

I have a program with over a 100 globals and about 20 locals, it works fine.
It would have been much harder to write using al local variabes, although possible, why should I waste time doing that?

For reasons of modularity, expandability, and thread safety.
12-16-2008
esbo

Quote:

Originally Posted by laserlight

The claims have been substantiated. You merely refuse to face the truth. "All you can give a lot of waffle basically."

In a way, you have a strawman argument, since it is indeed

Is it maintainable? Do you have a test suite? Are its components reusable with (almost) no modification?

It has been maintained, it started off basic and more and more functionality has been
added to it. It has also been 'ported' to work on 3 other poker sites, which store the
data in different ways, some put one history in a file, some several, some spread it over serveral folders, some use a mixture of the two, all use a different format for the history
with some similarities. It would prove too complex to have one multipurpose program
especially as I will add other sites of unknown formats.

Obviously I could have done some thing better with hindsight but not that much,
obviously you have to balance off forward planning with having a working version.

Each new feaure is tested.
It has been ran over a million poker hand histories, that is over a million files
in some cases. (obviously that take a while!!). It incorporates a database of a summary
of the previous results and loads it in real time and adds the next history to it.
You can get a commercial version called Pokertracker($98), I bet my version is quicker than that!! Obviously mine is not all singing all dancing but then it did not envolve
a million man hours!!

Quote:

Originally Posted by laserlight

Clearly, this means that you lack the skill to participate in the development of programs of significant size.

You have provided no jusification for that statement.
If you mean projects which end up having to be scrapped then probably yes.
I have worked on a project with a heavy empathis on variable scope which had to be
rewritted from scratch for other reasons. So that was largely a waste of time.

Quote:

Originally Posted by laserlight

No, the reason it is not a million lines long is because it is trivial.

It's not trivial just written by someone who is an efficient worker and knows how to
design and write a program which is actually useful.
12-16-2008
esbo

Quote:

Originally Posted by C_ntua

I think we need examples. Post some common examples like "here a lot use a global, but it could be avoided". Some users, I suspect many, don't have the experience in working for a big C project so all of this seems kind of undefined. I have only made 2 medium-small C projects (3-4K lines) and didn't find the need to use globals at all. I want to do something, I create a function that takes input and gives output. The data I pass all in a struct which I update and flags are again all in one struct that I pass (or could just have had one global variable, no big difference).

I don't think you pass a structure though do you?
You pass a pointer to a structure, so the function can modify the data.

Most of the data my program uses might at some time need to be accessed
by almost any function so it seems sensible to make most stuff global except for
some local variable in functions, loop counters etc...
I don't know what functionality I might want to add to it, so I don't want to have to
constantly have to change the data I have to pass to the functions, it would just
create an oppertunnity to introduce bugs every time I modified it.

Again it is hard to generalise about programs without a specific example.

Programs which are over structured tend to take on a rigidity which makes
them hard to modify quickly, for example whilst I am playing poker!!
Yes I sometimes write code as I play, sometimes when I am multi-tabling
which can be 'interesting' having to switch from program to poker quickly!!
If I then make a mistake I am then without the asistance of my program
and have to play without knowledge of the playing style of the players
aat the table. However often such 'knowledge' can be overvalued and dangerous
if the data indicates the player is a ''bluffer' but it turns out he has great hand!!

Also most of the time you never see the players again so it is largly a waste of
time gathering data but it does help sometimes when the the player pushes
all his chips in and the data indicates he is as tight as a vice. You can guarantee
he will usually hold AA KK or QQ, probably best to fold anyway ;)
12-16-2008
whiteflags

Quote:

Originally Posted by esbo

If you mean projects which end up having to be scrapped then probably yes.
I have worked on a project with a heavy empathis on variable scope which had to be
rewritted from scratch for other reasons. So that was largely a waste of time.

(snip)

It's not trivial just written by someone who is an efficient worker and knows how to
design and write a program which is actually useful.

Well don't talk as though local variables are the reason the projects that you work on tend to get scrapped. It is far more likely that you FUBAR'd them, if you had a significant role in the development of said software.

Also, Texas Holdem can be implemented trivially: you can write most card games for schoolwork if the I/O is lame enough, and you use rand as the PRNG. That's not a very convincing example on its own. Unless you want us to just give you the benefit of the doubt of course.

Perhaps that's for the best. You often worry about us stealing the code, maybe we'll steal the specs too! :devil:

Quote:

Originally Posted by esbo

I don't think you pass a structure though do you?
You pass a pointer to a structure, so the function can modify the data.

The situation you described does not make the pointer any less local to a function.

Quote:

Again it is hard to generalise about programs without a specific example.

Well apparently you fail to realize that if the shoe (the card decks in the game) and the shuffling algorithm are separate, self-contained entities it is trivial to integrate that code into another card game project, say, FreeCell. By spewing globals all over the place, you learn to rely on those and end up introducing interesting side effects to a program. That doesn't fascilitate code reuse. It isn't as easy as it could be to compile an already available shuffle, so you have to resolve the same, boring part of the project over and over again.

There are uses for global scoped stuff. But they are normally environment variables and not program data. Your inability to realise this is fascinating.

But then, you claimed to have maintained things before so who knows what sort of kluges you have up your sleeve to avoid whittling away at tedium.

Quote:

You can guarantee he will usually hold AA KK or QQ, probably best to fold anyway ;)

Every hand's a winner, every hand's a loser. You're playing with predictable people. :p
12-16-2008
esbo

Quote:

Originally Posted by whiteflags

Well don't talk as though local variables are the reason the projects that you work on tend to get scrapped. It is far more likely that you FUBAR'd them, if you had a significant role in the development of said software.

Nowt to do with me :)
Well maybe I spotted a big flaw in the design ;)
I joined it midway through. (then everything went pear shaped - lol)

Quote:

Originally Posted by whiteflags

Also, Texas Holdem can be implemented trivially: you can write most card games for schoolwork if the I/O is lame enough, and you use rand as the PRNG. That's not a very convincing example on its own. Unless you want us to just give you the benefit of the doubt of course.

What the program does is take a file such as below

Code:

Game #6682418603: Festive Freeroll (ID8701531) £0+£0 - Hold'em NL (75/150) - 2008/12/16 - 18:46:47 (UK) Table "8701531 - 120" Seat 1 is the button. Seat 1: Jacq5050 sits out Seat 2: Helokitty (2220 in chips) Seat 3: esbo(1635 in chips) Seat 4: _angela79 (4255 in chips) Seat 5: Sveto2609 sits out Seat 6: John135 (2630 in chips) Seat 7: Arsim0205 sits out Seat 8: Cojoc3101 sits out Seat 9: Donn20044 sits out Seat 10: __j_t__ (3050 in chips) Helokitty: posts small blind 75 Flastard: posts big blind 150 ----- HOLE CARDS ----- dealt to esbo[7c Ts] _angela79: calls 150 Sveto2609: folds John135: calls 150 Arsim0205: folds Cojoc3101: folds Donn20044: folds __j_t__: folds Jacq5050: folds Helokitty: calls 75 Flastard: checks ----- FLOP ----- [2d 2s 6c] Helokitty: checks Flastard: checks _angela79: checks John135: bets 300 Helokitty: folds Flastard: folds _angela79: folds Returned uncalled bets 300 to John135 John135: doesn't show hand John135 collected 600 from Main pot ----- SUMMARY ----- Total pot 600 Main pot 600 Rake 0 Board [2d 2s 6c] Seat 1: Jacq5050 (button) folded before Flop (didn't bet) Seat 2: Helokitty (small blind) folded on the Flop Seat 3: esbo(big blind) folded on the Flop Seat 4: _angela79 folded on the Flop Seat 5: Sveto2609 folded before Flop (didn't bet) Seat 6: John135 collected 600 Seat 7: Arsim0205 folded before Flop (didn't bet) Seat 8: Cojoc3101 folded before Flop (didn't bet) Seat 9: Donn20044 folded before Flop (didn't bet) Seat 10: __j_t__ folded before Flop (didn't bet)

And produce statistics on betting pattens etc (except properly aligned)

Code:

8764794 - 18.txt Marty02 52.0X -9810P 24G 13C 25G 13C 5.0W 60.0X8 15.5CX3 21%WON 1F 4%FW 17%P 17%F 0%T 4%R 033%SD Marty02 __simpy__ 18.2X 7510P 28G 8C 11G 2C 5.0W 33.3X8 11.1CX3 18%WON 3F 11%FW 7%P 18%F 11%T 11%R 050%SD __simpy__ Juan1908 33.3X 2071P 9G 7C 21G 7C 5.3W 50.0X8 11.9CX3 59%WON 4F 44%FW 44%P 33%F 22%T 11%R 044%SD Juan1908 Polipid1 0.0X -1720P 15G 2C 13G 0C 1.0W 0.0X8 5.9CX3 7%WON 0F 0%FW 7%P 0%F 0%T 0%R 050%SD Polipid1 esbo_____ 16.1X 40265P 84161G 13960C 78607G 12685C 7947.2W 15.6X8 16.4CX3 9%WON 4251F 5%FW 4%P 6%F 2%T 2%R 052%SD esbo_____ Rammy 50.0X 9818P 77G 54C 18G 9C 32.0W 38.5X8 66.7CX3 42%WON 22F 29%FW 21%P 19%F 13%T 8%R 045%SD Rammy Tyrant002 50.0X -15P 2G 1C 2G 1C 2.0W NaNX8 4.5CX3 100%WON 1F 50%FW 50%P 0%F 0%T 0%R 100%SD Tyrant002 Pme007 0.0X -680P 1G 0C 14G 0C 0.0W 0.0X8 0.0CX3 0%WON 0F 0%FW 0%P 0%F 0%T 0%R NaN%SD Pme007 Gav280216 0.0X -870P 1G 0C 10G 0C 0.0W NaNX8 0.0CX3 0%WON 0F 0%FW 0%P 0%F 0%T 0%R NaN%SD Gav280216 Poshtosh 46.2X 20230P 16G 7C 13G 6C 4.0W 46.2X8 21.9CX3 25%WON 3F 19%FW 6%P 12%F 19%T 19%R 050%SD Poshtosh

So " 5%FW 4%P 6%F 2%T 2%R 052%SD esbo_____" tells me I 'force' 5% of my wins, raise preflop 4% of the time, raise 6% of the time post flop, raise 2% of the time after the 'turn' and raise 2% of the time after the 'river' (last card), and win 52% of my 'showdowns'.

Other sites use different formats but some stuff is broadly the same.
That was a fairly simple game as not much bettiing too place.
Some sites miss information out so you have to work it out from the info given.

Also there are different types games, cash and tournements etc..

Quote:

Originally Posted by whiteflags

Perhaps that's for the best. You often worry about us stealing the code, maybe we'll steal the specs too! :devil:

The situation you described does not make the pointer any less local to a function.

Well apparently you fail to realize that if the shoe (the card decks in the game) and the shuffling algorithm are separate, self-contained entities it is trivial to integrate that code into another card game project, say, FreeCell. By spewing globals all over the place, you learn to rely on those and end up introducing interesting side effects to a program. That doesn't fascilitate code reuse. It isn't as easy as it could be to compile an already available shuffle, so you have to resolve the same, boring part of the project over and over again.

There are uses for global scoped stuff. But they are normally environment variables and not program data. Your inability to realise this is fascinating.

But then, you claimed to have maintained things before so who knows what sort of kluges you have up your sleeve to avoid whittling away at tedium.

Every hand's a winner, every hand's a loser. You're playing with predictable people. :p

Wish I was I like predictable people!!
People get more predictable as the stakes get higher, apart from the 'nutters'
12-16-2008
laserlight

Quote:

Originally Posted by esbo

It would prove too complex to have one multipurpose program
especially as I will add other sites of unknown formats.

Note that I did not ask whether the program was reusable. I asked whether the components are reusable. Trying to write a program to solve every possible future requirement is indeed a fruitless task. Trying to write a program that can be extended with minimal changing of the current source code, and whose components can be reused in a new program with similiar yet different requirements is both feasible and desirable.

Quote:

Originally Posted by esbo

It's not trivial just written by someone who is an efficient worker and knows how to
design and write a program which is actually useful.

You have provided no jusification for that statement. A 1200 line C++ program is typically trivial, at least when compared to say, the complexity and resulting number of lines of code required by a modern operating system. Of course, even a program with less than 100 lines of simple code can be useful, so by saying that your program was trivial I did not imply that it was not useful.

Quote:

Originally Posted by esbo

Most of the data my program uses might at some time need to be accessed
by almost any function so it seems sensible to make most stuff global except for
some local variable in functions, loop counters etc...
I don't know what functionality I might want to add to it, so I don't want to have to
constantly have to change the data I have to pass to the functions, it would just
create an oppertunnity to introduce bugs every time I modified it.

That implies that your functions are not designed to be cohesive, loosely coupled units. They do not "do one thing and do it well". This in turn makes them monolithic components that are hard to reuse.
12-17-2008
esbo

Quote:

Originally Posted by laserlight

Note that I did not ask whether the program was reusable. I asked whether the components are reusable. Trying to write a program to solve every possible future requirement is indeed a fruitless task. Trying to write a program that can be extended with minimal changing of the current source code, and whose components can be reused in a new program with similiar yet different requirements is both feasible and desirable.

The 'components' as such are to specific to the program, that the chance needing to
reuse then is so small that making them reusable is a waste of time.
I sometines copy the odd bit out, for example opening a few files, not worth doing much for than that.

Quote:

Originally Posted by laserlight

You have provided no jusification for that statement. A 1200 line C++ program is typically trivial, at least when compared to say, the complexity and resulting number of lines of code required by a modern operating system. Of course, even a program with less than 100 lines of simple code can be useful, so by saying that your program was trivial I did not imply that it was not useful.

Those operating systems are so big because they are badly designed.
It is because they fail to identify common components and constantly rewrite them,
they fail the test of reusablity. My programs are small because I don't keep re-inventing
the wheel.
The size of some programs these days is staggering beyond belief, what do they do?
Write every loop out!!?

I encounter some apallingly bad practices using programs, take this edit box for example.
It is a pathetic design.
For example, if I move the cursor past the end of this line and click, it goes to the end of the like - it's complete garbage. If I press down arrow it moves to the start of the next line, not just down - absolute rubbish.

Quote:

Originally Posted by laserlight

That implies that your functions are not designed to be cohesive, loosely coupled units. They do not "do one thing and do it well". This in turn makes them monolithic components that are hard to reuse.

No it does not. Most of the functions are so specific that they could never concieveable
be reused in another program. They are basically just bits of code which the program and that program alone uses several times. Thats why it is not a billion lines long!!
Big programs tend to be bad programs.
12-17-2008
laserlight

Quote:

Originally Posted by esbo

The 'components' as such are to specific to the program, that the chance needing to
reuse then is so small that making them reusable is a waste of time.

This contradicts your own statement that "It has also been 'ported' to work on 3 other poker sites, which store the data in different ways, some put one history in a file, some several, some spread it over serveral folders, some use a mixture of the two, all use a different format for the history with some similarities."

Quote:

Originally Posted by esbo

Those operating systems are so big because they are badly designed.
It is because they fail to identify common components and constantly rewrite them,
they fail the test of reusablity.

That at least some common components are repeated is probably true, but the underlying reason is the inherent complexity in the many problems that those programs solve.

Quote:

Originally Posted by esbo

My programs are small because I don't keep re-inventing
the wheel.

Since you are unable to reuse your components, it is obvious that you are merely bluffing.

Quote:

Originally Posted by esbo

The size of some programs these days is staggering beyond belief, what do they do?
Write every loop out!!?

As I noted, loop unrolling is not the cause for the size of large programs. It is also a gross exaggeration to suggest that professional developers manually unroll every loop.

Quote:

Originally Posted by esbo

I encounter some apallingly bad practices using programs, take this edit box for example.
It is a pathetic design.
For example, if I move the cursor past the end of this line and click, it goes to the end of the like - it's complete garbage. If I press down arrow it moves to the start of the next line, not just down - absolute rubbish.

This is a user interface issue and thus is separate from what we are discussing. (Besides, I do not agree with your conclusions, but then user interfaces are often a matter of taste.)

Quote:

Originally Posted by esbo

Big programs tend to be bad programs.

Unfortunately, that is true because they also almost certainly contain more bugs than small programs, assuming that programmers of similiar skill are involved in writing both the big and small programs.
12-18-2008
esbo

Quote:

Originally Posted by laserlight

This contradicts your own statement that "It has also been 'ported' to work on 3 other poker sites, which store the data in different ways, some put one history in a file, some several, some spread it over serveral folders, some use a mixture of the two, all use a different format for the history with some similarities."

There was one routine which I wish I had written a little better, it would have made it
easier to port and has been one of the things I have been meaning to do for a while
but as it does make much difference anyway I have not bothered yet.
Just a simple thing really, I should have 'tied' the length of a string to the striing.
eg strptr=inputstring, strnglen=strlen(inputstring);
It's not much work to modify though, and it would not always 'work' anyway.
The stuff you mention above would have been too difficult to implement really
especialy as I don't know all the formats used, and I really needed a working version
for my main site, it would literally have cost me money to try and implement that.
It's easy to say in an ideal world where you have no time or cost constraints.

One puts it histories in reverse time order ie newest first rather than last.
12-18-2008
esbo

Quote:

Originally Posted by laserlight

Since you are unable to reuse your components, it is obvious that you are merely bluffing.

There are just not really any cmponents which can be reused.
C already has a vast library or reusable components.
Most of the time it is qucker to write your own routine thann search the librarys!!

If you think you can extract all the data in less lines you are welcome to try!!
12-18-2008
vart

Quote:

Most of the time it is qucker to write your own routine thann search the librarys!!

Your jokes do not make me even smile... Stop advertising your nonsense...
12-18-2008
esbo

Quote:

Originally Posted by laserlight

This is a user interface issue and thus is separate from what we are discussing. (Besides, I do not agree with your conclusions, but then user interfaces are often a matter of taste.)

It a program just like an operating system there is no difference.
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.
12-18-2008
samf

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.
12-18-2008
anon

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.
12-18-2008
esbo

Quote:

Originally Posted by samf

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.

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.
12-18-2008
esbo

Quote:

Originally Posted by anon

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.

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.
12-18-2008
whiteflags

Quote:

Originally Posted by esbo

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.

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.
12-18-2008
laserlight

Quote:

Originally Posted by esbo

It's like a jig-saw, you have lots of little pieces I have one big picture.

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).

Quote:

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".

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.

All times are GMT -6. The time now is 02:00 PM.