----- Original Message -----
From: "George Greer" <greerga@CIRCLEMUD.ORG>
> This is a separate issue, that 'goto' and global variables aren't always
> evil, and that power supply labelled "do not open" isn't so dangerous if
> you know what you're doing. The issue is knowing when you actually know
> enough to be more than dangerous.
In general, I agree with you. While goto's and globals should be avoided
for a variety of reasons, there are times when they just make sense.
> This was Novell NetWare client library code so it was much more convoluted
> than that and wouldn't work in a single if(). In particular, I couldn't
> just bend the API to my whim and make the cleanup functions return the
> appropriate values.
int my_cleanup(void *var) { cleanup(var); return 0; }
> Your if() works when the planets and API are aligned on proper return
> values.
Or with a little forethought. My point is not to pick apart your example,
but to show that there are always a variety of ways to handle a particular
problem. One argument I've seen for goto's is their ability to break out of
nested loops:
void func() {
int i, j;
for (i = 0; i < 1024; i++) {
for (j = 0; j < i; j++) {
/* .... Do something useful */
if (/* condition */) goto bailout;
}
}
bailout:
/* Perform some sort of cleanup */
}
But this same thing can be accomplished by putting the loops in a function
and using a return to bail out instead of a goto.
> Tangents...
Just to get us back on track, let me expand on my earlier response about
globals. Most respondants seem to think that globals provide increased
performance, although there is actually a performance trade-off associated
with them. While saving allocation time, you are permanently increasing the
memory footprint of the application. This can lead to performance
degredation as well. There are two main risks to globals that spring to
mind. One is having nested function calls stomp on the values unwittingly,
the other is having functions rely on the values after they go out of scope
and then having the values stomped.
The second is probably unlikely, because it would take a pretty bonehead
decision to code something like that into Circle. The first is a little
more likely, but certainly avoidable it you're really attached to the
globals. This fits in with the point I was making about gotos. The globals
certainly can work, and they DO work just fine in my MUD. The real issue is
that they do nothing to discourage bad design (as in the two examples), so
poor programming is possible. While we certainly can do nothing to prevent
bad programming, as contributers to a codebase, we should feel an obligation
to at least decrease the risk.
I admit some of my opinion is based on an O-O bias that disagrees with
globals on principal. :)
Mike
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST