Server Help :: View topic - Terminating a Loop

Server Help

Bot Questions - Terminating a Loop

Zip - Fri Sep 03, 2004 7:58 pm
Post subject: Terminating a Loop

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 - Fri Sep 03, 2004 8:16 pm
Post subject:

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 - Fri Sep 03, 2004 8:25 pm
Post subject:

Code: Show/Hide

while (1)
{
if ()
break;

if ()
break;

if ()
break;
}

break jumps out of the inner-most while/for/do structure.

2dragons - Sat Sep 04, 2004 2:13 pm
Post subject:

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 - Sat Sep 04, 2004 2:42 pm
Post subject:

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

2dragons - Sat Sep 04, 2004 4:52 pm
Post subject:

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 - Sat Sep 04, 2004 5:15 pm
Post subject:

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 - Sat Sep 04, 2004 5:48 pm
Post subject:

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 - Sat Sep 04, 2004 6:21 pm
Post subject:

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 - Sat Sep 04, 2004 9:44 pm
Post subject:

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

D1st0rt - Sat Sep 04, 2004 10:07 pm
Post subject:

Ekted, so basically this would be bad?

Code: Show/Hide

void foo(int n)
{
if(n < 0) return;

//lots of code here
}

CypherJF - Sat Sep 04, 2004 10:13 pm
Post subject:

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.

D1st0rt - Sat Sep 04, 2004 10:17 pm
Post subject:

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 - Sat Sep 04, 2004 11:37 pm
Post subject:

D1st0rt wrote:

Ekted, so basically this would be bad?

Code: Show/Hide

void foo(int n)
{
if(n < 0) return;

//lots of code here
}

Yes it is. Think of a function as having 3 parts: init, main, cleanup. A return in the middle says "skip the cleanup". Even with tiny funcs it's good practice. I can't tell you the number of times I have seen resource/memory leaks etc caused by internal returns. It's also nicer when you are looking at the function. You know the code "always gets here". You can see what's being cleanup. Less chance of mistakes, easier on the eye.

Smong - Sun Sep 05, 2004 6:40 am
Post subject:

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

50% Packetloss - Sun Sep 05, 2004 11:17 am
Post subject:

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 - Sun Sep 05, 2004 11:24 am
Post subject:

Smong wrote:

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

They are identical in function and performance. I like to use for loops only when I have a specific start/end conditions. I also never initialize or modify anything but the loop counter in the for statement.

Mine GO BOOM - Sun Sep 05, 2004 1:24 pm
Post subject:

50% Packetloss wrote:

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

Did you test this with an optomized code, because almost all smart compilers should make them identical in assembly.

50% Packetloss - Sun Sep 05, 2004 2:57 pm
Post subject:

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

Solo Ace - Sun Sep 05, 2004 3:56 pm
Post subject:

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

Cyan~Fire - Mon Sep 06, 2004 11:37 am
Post subject:

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 - Mon Sep 06, 2004 12:38 pm
Post subject:

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

Cyan~Fire - Mon Sep 06, 2004 3:19 pm
Post subject:

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 - Mon Sep 06, 2004 3:35 pm
Post subject:

Cyan~Fire wrote:

Disagreed. Always bad style. Window procs return a value, just like any other function. Besides, you shouldn't have lots of code in your window proc; you should be calling handler functions.

Anonymous - Mon Sep 06, 2004 6:51 pm
Post subject:

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

Mr Ekted - Mon Sep 06, 2004 7:06 pm
Post subject:

If your debugger can't step into any line of source code, then it's not a real debugger. And if you can't handle stepping into an extra level of function calls in ASM, then don't program.

Cyan~Fire - Mon Sep 06, 2004 9:47 pm
Post subject:

So what do you recommend here?

Code: Show/Hide

case WM_INITDIALOG:
for (i = 0; i < NUM_MSGS; i++)
SendDlgItemMessage(page, IDC_M_SEL, CB_ADDSTRING, 0, (LPARAM)message_names[i]);
for (i = 0; i < NUM_CINEM; i++)
SendDlgItemMessage(page, IDC_M_SELC, CB_ADDSTRING, 0, (LPARAM)cinem_names[i]);
return TRUE;

50% Packetloss - Mon Sep 06, 2004 10:42 pm
Post subject:

You break; out of the switch. Never have a return except at the end of the function.

Mr Ekted - Tue Sep 07, 2004 12:24 am
Post subject:

Code: Show/Hide

BOOL DialogProc (...)
{
BOOL ret = FALSE;

...

switch (msg)
{
...

case WM_INITDIALOG:

for (i = 0; i < NUM_MSGS; i++)
SendDlgItemMessage(page, IDC_M_SEL, CB_ADDSTRING, 0, (LPARAM)message_names[i]);

for (i = 0; i < NUM_CINEM; i++)
SendDlgItemMessage(page, IDC_M_SELC, CB_ADDSTRING, 0, (LPARAM)cinem_names[i]);

ret = TRUE;
break;

...
}

return (ret);
}

Glad to see you are using raw Win32.

Almost all messages you return FALSE if you handle them, so set return once at top, and only change in special cases.

Cyan~Fire - Tue Sep 07, 2004 12:56 am
Post subject:

It's still ugly though... and it's not like having a return there is a safety hazard in any way. I just don't think we all should be so strict about it.

On a side note, I #included the old iostream headers today in Dev-C++ and it complained at me for not using those darned template classes. Like I really need all that code bloating the size of my executable? Basically, I say all us likers of clean code (even if we do disagree on returns) should stage a coup d'etat against ANSI, MS, and Mr. Plauger and rule the world in its place. Or maybe I'm just really too tired to be talking.

Mine GO BOOM - Tue Sep 07, 2004 1:03 am
Post subject:

Cyan~Fire wrote:

Like I really need all that code bloating the size of my executable?

I'm sure nothing you are making right now even comes close to the efficiency of making a program that will need real-time speed. And the size of the executable is negligable for what you are working with.

Cleanliness isn't always the best. Whats important, is that someone else ten years from now is able to look over your source code, understand most of what is there without reading any outside information (ie: no manual, only source comments), and be able to modify it or convert it to what he needs. If that means making your source a bit ugly at a glance, so that someone can determine what you are doing, thats a good trade off.

Mr Ekted - Tue Sep 07, 2004 4:39 am
Post subject:

Cyan~Fire wrote:

If you look at each function and decide "this one doesn't need to be so strict" and "this one does", then you fall into the trap of making a mess as you edit, design, maintain, and evolve. You will often find that a simple function where you didn't care suddenly got more complex. But you don't have the time right now to fix it, so it gets big and buggy. What would have taken 5 seconds to do right the first time now takes you a week to debug. I've seen it over and over: malloc/free, open/close, create/destroy, new/delete, uninitialized variables, things that make your app a system hog but not crash, etc.

I don't know your experience level, your career, or how old you are, but I think you will find yourself becoming more strict as you go after betting burned or watching it happen in other people's code in the same project you are one (when you have to work all weekend to find the function they didn't care to design right).

Cyan~Fire - Tue Sep 07, 2004 10:34 am
Post subject:

MGB wrote:

I like to keep my executables small. There is also a C runtime library I use to do so. If it's going to get mad at me about using that CRT, I'm going to get mad at it. The whole effeciency/size thing is not that I think it will make a difference in the program, it's just that it could always be better so I will always be trying to make it better.

Ekted wrote:

If you look at each function and decide "this one doesn't need to be so strict" and "this one does", then you fall into the trap of making a mess as you edit, design, maintain, and evolve.

Except that I never use mid-function returns unless it's a function that's never going to do anything that requires cleanup. And in my WindowProcs, I just use break if it's going to return 0 and return something else if necessary. If the 'something else' ends up complex enough to need cleanup, I stick it in a handler anyway.

Ekted wrote:

I don't know your experience level, your career, or how old you are, but I think you will find yourself becoming more strict as you go after betting burned or watching it happen in other people's code in the same project you are one (when you have to work all weekend to find the function they didn't care to design right).

My programming is purely hobbyist right now, but AFAIK I'll end up in a corporate environment. If I have to deal with others' messy code, I'm going to have to worry about a heck of a lot more than returns, I believe. However, if my current plan of things works out, I'm going to be co-founding a video game company... but that's probably just pretentions.

Mr Ekted - Tue Sep 07, 2004 2:02 pm
Post subject:

Quote:

However, if my current plan of things works out, I'm going to be co-founding a video game company... but that's probably just pretentions.

I'll work for you.

CypherJF - Tue Sep 07, 2004 3:39 pm
Post subject:

rotfl...

Cyan~Fire - Tue Sep 07, 2004 7:50 pm
Post subject:

More like I'll work for you, since I'm sure you wouldn't ever want me controlling what you code

Mr Ekted - Tue Sep 07, 2004 9:33 pm
Post subject:

Cyan~Fire wrote:

More like I'll work for you, since I'm sure you wouldn't ever want me controlling what you code

No one I've ever worked for controlled my code. You hire really good people, pay them whatever they want, and let them do whatever they want. That's how you get results. Hiring people that will work for 50K, putting them in rows of cubicles, managing them with unqualified people (ie non-techies), making them work 9-5, go to meetings, fill out time sheets, dress codes, or expecting everyone to conform to some arbitrary system is a sure-fire way to make sure that progress and morale are crap.

3 people in the first situation can out-perform 30 in the second.

Smong - Thu Sep 09, 2004 4:35 pm
Post subject:

And if Ek works for Cyan he will never be out of a job constantly cleaning up his code.

Cyan~Fire - Thu Sep 09, 2004 4:44 pm
Post subject:

Fixing my returns... hahaha.