Member Discussions

Hello,

I'm a Computer Information Systems major looking to start on a Marvel Universe based mud. My reason for posting here is that I am in search of anyone knowledgeable in C to help me along as the friendly compiler returns many errors. I'm also having difficulty understanding some of the functions which have already been implemented.

Im not looking for somebody to do it for me. I just have many questions as I am a novice. I want to do it myself. If interested please e-mail me or respond to this post.

Thanks,
Harrisi

(Comment added by Harrisi on Mon Feb 19 21:09:29 2007)

** I've decided to use Jobo's SocketMUD cb to work with.

You could just post the errors here, and I'm sure people would be willing to help out (such as myself). ;)

I could, but Im not interested in becoming a prospect for the flame game.

You'll only get flamed if you post something controversial and/or political. Introductory programming usually doesn't fall into that category unless you start espousing the virtues of GOTO ;)

GOTO has some legitimate uses for readable code, particularly in needing to break all the way out of a nested set of loops. Dijkstra should be considered harmful.

GOTO has some legitimate uses for readable code, particularly in needing to break all the way out of a nested set of loops. Dijkstra should be considered harmful.

<flame mode>
If you need goto for that reason you have created a function that is way too big and complex to be readable to begin with, in other words, it means your code sucks already.
</flame mode>

Throw/catch is a lot safer than goto and does what you are espousing goto to be good at.

http://david.tribble.com/text/goto.html

Contains some thoughtful annotation of Dijkstra's original essay on how goto can be harmful, along with some examples of where it can be useful. I don't know Dijkstra's opinion on Tribble's annotations of his letter, but Tribble puts forth:

"What Dijkstra means by the goto statement as it stands is otherwise known as an unstructured goto. That is, a goto statement with no restrictions about how it may be used in an otherwise structured language."

And therefore:

"Limiting the use of gotos to a few simple, well-structured controls such as exiting early from loops, error handling (a.k.a. exceptions), and the like brings the goto statement back into the realm of structured control flow modification. But without rules that enforce these limitations, the goto statement provided by a language cannot be said to be truly well-structured."

(Comment added by Drey on Wed Feb 21 12:00:22 2007)

I suppose this discussion isn't actually complete without a link to Dijkstra's original writing:

http://www.acm.org/classics/oct95/

And then, of course, we have Donald Knuth's writing on using goto in structured programming:

http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

Knuth is a heavy-weight in CompSci, as you must know.

"Throw/catch is a lot safer than goto and does what you are espousing goto to be good at."

Some languages don't have try/catch/throw statements. Even in the ones that do, there are places you might use a goto that those statements wouldn't work for anyhow. I've posted some links to articles showing acceptable uses of goto, including an article by Donald Knuth.

That Knuth article is very old. I skimmed it, and the reasons he gives appear to be mostly for efficiency: specifically, for very small amounts of efficiency. Making something n log( n )instead of n^2 is worthwhile; making something 4n instead of 6n is not worthwhile any more. I doubt that he would still advocate gotos for the same reasons today.

He uses the same article to rail against boolean variables, apparently for similar reasons.

"Limiting the use of gotos to a few simple, well-structured controls such as exiting early from loops, error handling (a.k.a. exceptions), and the like brings the goto statement back into the realm of structured control flow modification. But without rules that enforce these limitations, the goto statement provided by a language cannot be said to be truly well-structured."

Exiting early from loops can be done in at least 2 different ways.

1. Use of the break statement (which can be argued to be a goto in disguise of course)

2. Making the early exit condition part of the loop condition, ie:

while (expression || exitnow) {
...
}

"That Knuth article is very old."

So is the Dijkstra article so many swear by and probably haven't read. /sigh

"Exiting early from loops can be done in at least 2 different ways."

The place where the 'goto' becomes efficient and lends to more readable code is when you have embedded loops and need to break out of all of them from one of the inner loops and not the top-most loop. You can also use boolean variables and use them as an escape clause of each loop. It's really just a preference.

I was responding to the "all goto's are evil", which just isn't true, hence my tongue-in-cheek reference to Dijkstra's article.

I've created a monster... *hangs head in shame*

"I've created a monster... *hangs head in shame*"

Haha ... so now that that's out of the way, gonna post some of the code with error messages so we can help you out? :-)

The place where the 'goto' becomes efficient and lends to more readable code is when you have embedded loops and need to break out of all of them from one of the inner loops and not the top-most loop. You can also use boolean variables and use them as an escape clause of each loop. It's really just a preference.

Not every use of goto is evil, no. But there are very few if any cases where there isn't an alternative in most programming languages. Something that by its very nature breaks the deterministic behavior of a program should be avoided whenever you can, and every use of goto where there is such an alternative is evil for that simple reason. Of course for the breaking out of nested loops there is another already mentioned alternative, and you really don't need gotos for it. That is nto a matter of preference either, it is a matter of the alternatives existing in the language you are using.


Ok.. and now we have demonstrated Drey how we can have a very silly and potentially flamy discussion regardless of him posting his code, I'll stop this 'thread hijacking' and go back under my bridge.

I dont have any errors yet. I'm still trying to figure out how the game loop works...

Ah, I thought I saw you mention compiler errors earlier. No worries, what sort of questions do you have about the game loop?