Server Help

[Zip]

Im wondering what the best way to terminate a loop is, stop it from continuing. Maybe its not possible in this situation but I dont think thats the case. Here is the Methot that I tried, which also crashed the bot. This isnt an exact copy paste but shows the structure.

bool die=false;

Code: Show/Hide while(die == false) { an If statment { bla bla bla  die=true} an If statment {another 'If'{blablabla die=true;} bla bla bla  die=true;} an If statment {another 'If'{blablabla die=true;} bla bla bla  die=true;} And so on }

I wasnt sure if there is a predefined function for terminating a loop.
Or do I need to have something in the "case EVENT_Tick:" to check if die has been set to true??
true and false doesnt need to be capitalized right?
[/code]

[Zip]

mm thats not even whats causeing it to crash but just the same how do you terminate a loop before it reaches the end of one loop?

[Mr Ekted]

Code: Show/Hide while (1)    {    if ()       break;    if ()       break;    if ()       break;    }

break jumps out of the inner-most while/for/do structure.
_________________
4,691 irradiated haggis!

[2dragons]

However using break is not a good programming practice.
Break is as bad as using goto or continue.

The expression you evaluate in your loop should break you out of it.

[Cyan~Fire]

What?

I'll agree with goto, since goto should really be a "hidden" ASM thing, but break and continue are high-level enough to be useful. And they're not at all dangerous. The ASM code for a loop basically uses the same as break and continue normally in a loop...
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[2dragons]

Heheh, continue and break are just covered versions of goto. All 3 have nearly have the same problem of making code hard to understand and maintain.

[50% Packetloss]

Umm, breaks are not high level. They are the equivelent of an unconditional branch (Aka BRA). Continues and breaks are perfect, ekted would not give you bad info. He has been programming all his life, i think he knows what he is talking about.

This is how a branch works. Depending on if its conditional or not, it will check flags that are set after arethmetic operations. If the flag its checking matches up to what it wants then it will execute the branch by adding a number to the program counter. So something such as BEQ (branch if equal to 0) if the Zero flag is set, the branch will occur and the 1 or 2 hex numbers after the opcode will be added to the program counter. Branches are used for loops and for jumping around within sections of code.

A goto is competely different, in a goto you are taking the program counter and completely changing the value. This is often risky and a branch is better.

[2dragons]

branch/continue are anagolous with goto, they both can jump to other sections of code, the only think with break/continue is they are bounded

[Mr Ekted]

I disagree with everyone. Break, goto, and continue are very good things to use, each in their proper place. The only bad one to use is return in the middle of a function. People will argue that it's just opinion, but my statement comes from 20 years of coding and dealing with others' code. The bottom line is, anything is ok if you know what you are doing. You can make "proper" code by making it look ugly, or you can do it right and make it elegent.

Look at the unexpected bug induced by the first code sample above. And see how my code does it right.

[Cyan~Fire]

I didn't say they were high-level. I said they were high-level enough, which is basically exactly what you said, 50%.

[D1st0rt]

Ekted, so basically this would be bad?

Code: Show/Hide void foo(int n) {     if(n < 0) return;     //lots of code here }

_________________

[CypherJF]

Technically according to Ekted, yes that would be bad.

Code: Show/Hide void foo(int n) {      if (n >= 0)      {           //code here...       } }

Personally I'd add the pre/post conditions as documentation ie:

Code: Show/Hide void foo(int n) { //Pre: n must be an integer >= 0. //Post: (w/e the function does as a result.)      if (n >= 0)      {           //code here...       } }

Heck thats a really crappy pre/post condition but it'd work.
_________________
Performance is often the art of cheating carefully. - James Gosling

[D1st0rt]

To me, that doesn't look as clean. I tend to try and keep my bracket structures as simple as possible. Then again I really know very little about programming. Level 0.1 Knowledge on the Ekted Scale w00t!

[Mr Ekted]

[Smong]

Going back to the loop, is while(1) better than for(;;)?

[50% Packetloss]

Code: Show/Hide while(1) 0041470E  mov         eax,1 00414713  test        eax,eax 00414715  je          main+29h (414719h)    {    } 00414717  jmp         main+1Eh (41470Eh)    for(;;)    {    } 00414719  jmp         main+29h (414719h)

while sets up a conditional jump while the for loop will just loop forever in this case. So ASM wise, an infinate FOR loop takes less code

[Mr Ekted]

[Mine GO BOOM]

[50% Packetloss]

I dont know, I used VC++ .net. It seems logical that it would do that though

[Solo Ace]

Optimization is disabled in VC++.net in debug mode.

[Cyan~Fire]

Code: Show/Hide int foo(int n) {    if (n > 0)       return 1;    else if (n < 0)       return -1;    else       return 0; }

Pretty.

Code: Show/Hide int foo(int n) {    int ret;    if (n > 0)       ret = 1;    else if (n < 0)       ret = -1;    else       ret = 0;    return ret; }

Ugly.

[Mr Ekted]

You will remember this thread in 10 years when you get severely bitten by this coding style.

[Cyan~Fire]

I don't use this style in cases that you have said are dangerous. I only use it in cases like the above, or in window procedures.

It especially makes sense to use multiple returns in window procs since, depending on the message, the function's code is completely different and isolated from the rest.

[Mr Ekted]

[-Smong-]

I read somewhere the more handler functions you use the harder it is to use a debugger on the program.