switch(polyPtr->PolyItemType)
{
#if debug
case I_Polyline:
case I_FilledPolyline:
case I_Wireframe:
/* NB This is intended to fall through to the GouraudPolygon case */
#endif
// case I_Gouraud3dTexturedPolygon:
case I_GouraudPolygon:
case I_Gouraud2dTexturedPolygon:
case I_Gouraud3dTexturedPolygon:
case I_2dTexturedPolygon:
case I_3dTexturedPolygon:
case I_ZB_2dTexturedPolygon:
case I_ZB_3dTexturedPolygon:
{
// LOCALASSERT(0);
break;
}
case I_ZB_GouraudPolygon:
{
<- LOTS OF CODE HERE ->
}
case I_ZB_Gouraud3dTexturedPolygon:
case I_ZB_Gouraud2dTexturedPolygon:
{
<- CODE I NEED TO RUN ->
}
Switch case behaviour confusing me..
Author
Hey,
Dealing with some code here I didn't write that would have originally been compiled in Visual C++ 6.0 or Watcom..something with a fairly old C/C++ compiler :)
I'm compiling this on Visual Studio C++ 2005 Standard.
Here's a bit of the code:
The case i'm expecting to be met is 'case I_Gouraud3dTexturedPolygon:' but I see this doesn't have a case specified.
Switch statements *should* ignore any case with no break; in it and drop down to the next switch, i'm assuming. This doesn't happen when I compile under VS 2005. It doesn't "drop" through the cases.
If I copy the code from the case I need to run into the case 'I_Gouraud3dTexturedPolygon' then everything works as expected.
Why is this? is this because VS 2005 is more C++ compliant, and this code is the "wrong" way to do switch cases, or..?
If polyPtr->PolyItemType is I_Gouraud3dTexturedPolygon, then it will drop through all the case statements and hit the LOCALASSERT(0); line (Well, if it wasn't commented out). And that behavious is in VC6 or 2005 (Or any C/C++ compiler).
Basically you can think of a switch/case statement as a goto command, and break as "goto end of switch statement". If you hit another case blah: line before hitting a break, it's ignored.
Well, sort of anyway [smile]
Basically you can think of a switch/case statement as a goto command, and break as "goto end of switch statement". If you hit another case blah: line before hitting a break, it's ignored.
Well, sort of anyway [smile]
Author
Yeah, that LOCALASSERT is commented out in the original code too.
Do you know what that actually does?
I need it to drop down to the 3rd case listed in the code, but surely once it drops down through to the first case with the break; in it, it'll stop, and never reach the 3rd case where I need it to be?
Do you know what that actually does?
I need it to drop down to the 3rd case listed in the code, but surely once it drops down through to the first case with the break; in it, it'll stop, and never reach the 3rd case where I need it to be?
Quote:Original post by sirlemonhead
The case i'm expecting to be met is 'case I_Gouraud3dTexturedPolygon:' but I see this doesn't have a case specified.
Then it will skip all the cases, and if a default is specified, it will jump into that, otherwise it will just stay out of the entire switch statement.
I'm not 100% clear on what it is you expect of the code, and what actually happens. *if* polyPtr->PolyItemType == I_Gouraud3dTexturedPolygon, and I_Gouraud3dTexturedPolygon is uncommented, then it will match that case, and from there, fall through all the following cases until it encounters a break (in case I_ZB_3dTexturedPolygon).
If I_Gouraud3dTexturedPolygon is commented out as in the code you showed, then it won't enter any of the cases.
At least, that's what the compiler *should* behave like. VC6.0 is known to be buggy and emit erroneous code, on top of its lousy standards compliance.
Author
default just has break; in it
I_Gouraud3dTexturedPolygon is commented out at the top, but it's there a second time uncommented (was like that in the original code, sorry for the confusion)
My original problem with this code was that no level geometry was rendering in the game. I did some tracing back through code, and using OutputDebugString, found out that polyPtr->PolyItemType was constantly set as 'I_Gouraud3dTexturedPolygon'
The code from the third case 'I_ZB_Gouraud2dTexturedPolygon' Is the code I need because If I copy the code from that into the 'I_Gouraud3dTexturedPolygon' case, then the level renders fine and everything is ok.
So it *should* be dropping down to the 3rd case when 'polyPtr->PolyItemType == I_Gouraud3dTexturedPolygon'
I_Gouraud3dTexturedPolygon is commented out at the top, but it's there a second time uncommented (was like that in the original code, sorry for the confusion)
My original problem with this code was that no level geometry was rendering in the game. I did some tracing back through code, and using OutputDebugString, found out that polyPtr->PolyItemType was constantly set as 'I_Gouraud3dTexturedPolygon'
The code from the third case 'I_ZB_Gouraud2dTexturedPolygon' Is the code I need because If I copy the code from that into the 'I_Gouraud3dTexturedPolygon' case, then the level renders fine and everything is ok.
So it *should* be dropping down to the 3rd case when 'polyPtr->PolyItemType == I_Gouraud3dTexturedPolygon'
Oh, hadn't noticed there was an uncommented version of it too.
Anyway, the behavior you see sounds just like C++ *should* behave. If you want to fall through to the I_ZB_Gouraud2dTexturedPolygon case, you could just reorder the cases. As it is I_Gouraud3dTexturedPolygon falls through down to I_ZB_3dTexturedPolygon, where it breaks and exits the switch statement. Moving the I_Gouraud3dTexturedPolygon case down below that would be one way to solve the problem.
Anyway, the behavior you see sounds just like C++ *should* behave. If you want to fall through to the I_ZB_Gouraud2dTexturedPolygon case, you could just reorder the cases. As it is I_Gouraud3dTexturedPolygon falls through down to I_ZB_3dTexturedPolygon, where it breaks and exits the switch statement. Moving the I_Gouraud3dTexturedPolygon case down below that would be one way to solve the problem.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
