void DrawButtons(int iGameState)
{
for (int i=0;i<MAX_BUTTONS;i++) //loop through all of our buttons and find one that is not used in the struct
{
switch(iGameState)
{
case GS_INTRO:
{
if (MyButtons.GameState == GS_INTRO && MyButtons.ButtonID > 0) //we found a non blank button
{
DrawButton(i);
}
}break;
case GS_MAINMENU:
{
if (MyButtons.GameState == GS_MAINMENU && MyButtons.ButtonID > 0) //we found a non blank button
{
DrawButton(i);
}
}break;
case GS_GAMEROOMSELECT:
{
if (MyButtons.GameState == GS_GAMEROOMSELECT && MyButtons.ButtonID > 0) //we found a non blank button
{
DrawButton(i);
}
}break;
case GS_GAMESTART:
{
if (MyButtons.GameState == GS_GAMESTART && MyButtons.ButtonID > 0) //we found a non blank button
{
DrawButton(i);
}
}break;
case GS_TRANSITION:
{
//no buttons in transition (why would you want one)
}break;
}//end switch
}//end for loop
}
Breaking a switch and a for loop?
Author
I have a function that has a for loop and then a switch inside of it, if I break from inside the switch does that also break the for loop? the code works fine im just not sure if its doing what its supposed to =p
No, it will only break out of the switch, not out of the loop.
Similarly, if you had a break inside a loop inside another loop, then it would only break out of the inner loop.
Similarly, if you had a break inside a loop inside another loop, then it would only break out of the inner loop.
break; breaks out of the CURRENT construct. Your application should NOT be breaking out of the for loop. If you really want to write bad code, replace the entire thing with gotos. In the case of switch statements, using break is acceptable, since its a part of the actual construct. [lol]
I've been known to break out of a for loop like this:
But only as a way to mock the examiner in a C test.
[Edited by - speciesUnknown on February 20, 2008 11:29:44 PM]
I've been known to break out of a for loop like this:
int break_out = 0;for( x=0; (x<10 && !break_out); x++){ if(whatever) break_out = 1;}But only as a way to mock the examiner in a C test.
[Edited by - speciesUnknown on February 20, 2008 11:29:44 PM]
Ah yes, the ole premature closure argument.
Let's be frank -- production code has this sort of stuff in it all the time. CS profs disliking break have not stopped hojillions of client programmers sticking it in code all over the place. Generally speaking, the only time you want to get out of a loop early is when you've hit some sort of condition that means looping is no longer warranted or perhaps even possible. Many languages have a tool for solving this problem! ;)
While(condition holds)
{
Do stuff!
}
Different depending on which language you use -- but designed to allow you to hop out when you meet some condition -- much nicer than breaking out of a for-loop :)
That said, break shouldn't always be avoided -- it was put in for a reason after all. You ought to be careful however, because if you were to do something silly like allocate unmanaged memory in a nested scope such as a loop...and then break out prematurely -- you may end up with leaks. Some languages like C# & Java clean up the stuff you create in a loop (unless you went to lengths to avoid it...naughty!), but most of the time you should be a bit careful :)
~Shiny
Let's be frank -- production code has this sort of stuff in it all the time. CS profs disliking break have not stopped hojillions of client programmers sticking it in code all over the place. Generally speaking, the only time you want to get out of a loop early is when you've hit some sort of condition that means looping is no longer warranted or perhaps even possible. Many languages have a tool for solving this problem! ;)
While(condition holds)
{
Do stuff!
}
Different depending on which language you use -- but designed to allow you to hop out when you meet some condition -- much nicer than breaking out of a for-loop :)
That said, break shouldn't always be avoided -- it was put in for a reason after all. You ought to be careful however, because if you were to do something silly like allocate unmanaged memory in a nested scope such as a loop...and then break out prematurely -- you may end up with leaks. Some languages like C# & Java clean up the stuff you create in a loop (unless you went to lengths to avoid it...naughty!), but most of the time you should be a bit careful :)
~Shiny
You could create a flag used to determine if it should break out, and just check it after the switch statement. Or you could use a goto, or turn the switch into a nested if/else and use break, or rewrite your code so you don't face this problem. No one ever said you needed to like your options :p
If this is the only thing the function is doing, you could simply return.
If this is the only thing the function is doing, you could simply return.
Author
Quote:Original post by gekko
If this is the only thing the function is doing, you could simply return.
Good Idea! =)
Hm, switching over gamestates... wasnt there a nice OO pattern for this to replace the switch? :)
I don't know, but I'd replace the above with:
void DrawButtons(int iGameState){ if (iGameState != GS_TRANSITION) { for (int i=0;i<MAX_BUTTONS;i++) //loop through all of our buttons and find one that is not used in the struct { if (MyButtons.GameState == iGameState && MyButtons.ButtonID > 0) { DrawButton(i); break; } }//end for loop }}
How about this...
void DrawButtons(int iGameState)
{
for (int i=0;i<MAX_BUTTONS;i ++ )
{
bool flag = true;
if( iGameState == GS_TRANSITION) flag = false;
if(MyButtons.GameState != iGameState) flag = false;
if(MyButtons.ButtonID <= 0) flag = false;
if(flag)
{
DrawButton(i);
//return; if u wish u can return here
}
}
}
//errrrrrr how can I format the text?? It's removing the spaces :(
void DrawButtons(int iGameState)
{
for (int i=0;i<MAX_BUTTONS;i ++ )
{
bool flag = true;
if( iGameState == GS_TRANSITION) flag = false;
if(MyButtons.GameState != iGameState) flag = false;
if(MyButtons.ButtonID <= 0) flag = false;
if(flag)
{
DrawButton(i);
//return; if u wish u can return here
}
}
}
//errrrrrr how can I format the text?? It's removing the spaces :(
Quote:Original post by Antheus
I don't know, but I'd replace the above with:
*** Source Snippet Removed ***
hmmmm
a small explaination..
My previous post didn't target u.
It targets the author.
Both of us posted in almost same time :D
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
