Bad Coding?

[James R Twine]

I bumped into this sad example while working with a "professional" charting library that I am forced to use. This code (changed to protect the guilty) comes from the drawing code in one of the charting code's base classes     switch( dwSomeValue )     {         case SOME_CHARTTYPE1:         case SOME_CHARTTYPE2:         case SOME_CHARTTYPE3:         case SOME_CHARTTYPE4:         case SOME_CHARTTYPE5:         {             //             // Some Code...             //             break;         }         default:         case SOME_CHARTTYPE6:         case SOME_CHARTTYPE7:         case SOME_CHARTTYPE8:         case SOME_CHARTTYPE9:         case SOME_CHARTTYPE10:         {             //             // Some Other Code...             //         }     }    So now when a custom value (chart) is added, for example "SOME_NEW_CHARTTYPE11", the "Some Other Code" code block always gets executed, because the "default:" was placed in the middle of the switch statement, with no "break;" after it! :omg:    Now, I may be wrong here, but I am pretty sure that this is a bug in the charting class' code.  What I really want to know is, can anyone provide me with an example where (mis)using a "default" in the middle of a switch statement like this is a good idea?    Peace! -=- James.

[Roger Allen]

I have what I think is an example. I used it in a PreTranslateMessage for keystrokes. I need only certain keys to get through to the target window, so the default would cover all those unknown keys that M$ would add in the future. I obviously don't want my control to handle them. Roger Allen Sonork 100.10016 If I'm not breathing, I'm either dead or holding my breath. A fool jabbers, while a wise man listens. But is he so wise to listen to the fool?

[James R Twine]

(Note that I am not asking about uses for the "default" clause...)    If I understand you correctly, I think your example can be implemented with a "default:" clause at the end of the switch statement, correct? For example: switch( uiKey ) {     case VK_A:     {         // Do Something...         break;     }     case VK_B:     {         // Do Something Else...         break;     }     default:     {         // Ignore This Key...         break;     } }    My question specifically asks about a "default" clause in the middle of a switch, with no "break;", followed by other "case" values.    Peace! -=- James.

[Igor Proskuriakov]

That code is definitely an example of bad coding. The thing is that it is equivalent to the code where SOME_CHARTTYPE6, SOME_CHARTTYPE7, SOME_CHARTTYPE8, SOME_CHARTTYPE9, SOME_CHARTTYPE10 are ommited. I.e. the code can easily look like the following: switch( dwSomeValue ) { case SOME_CHARTTYPE1: case SOME_CHARTTYPE2: case SOME_CHARTTYPE3: case SOME_CHARTTYPE4: case SOME_CHARTTYPE5: { // // Some Code... // break; } default: { // // Some Other Code... // } } Igor Proskuriakov

[Chris Losinger]

I agree, that's some bad coding. Here's some questionable coding i found in a widely used TIFF reading library

#define REPEAT8(op) REPEAT4(op); REPEAT4(op)
#define REPEAT4(op) REPEAT2(op); REPEAT2(op)
#define REPEAT2(op) op; op

#define CASE8(x,op) \
switch (x) { \
case 7: op; case 6: op; case 5: op; \
case 4: op; case 3: op; case 2: op; \
case 1: op; \
}

#define UNROLL8(w, op1, op2) { \
uint32 _x; \
for (_x = w; _x >= 8; _x -= 8) { \
op1; \
REPEAT8(op2); \
} \
if (_x > 0) { \
op1; \
CASE8(_x,op2); \
} \
}

// then, later on in the code:

while (h-- > 0) {
uint32* bw;
UNROLL8(w, bw = PALmap[*pp++], *cp++ = *bw++);
cp += toskew;
pp += fromskew;
}

not only is this totally wierd, it is also a complete pain in the ass to debug (cause you can't step into a macro). those UNROLL8 things get expanded into loops of switch statements which are actually unrolled loops themselves, or into repetitions of statements. aahhhHH!!! i had to unroll this code to use it in another app. i almost went crazy. this really crunches a lot of code into a few terse macros. but holy crap.. it's impossible to understand. -c

---

Smaller Animals Software, Inc.

[Joaquin M Lopez Munoz]

Though I'm not recommending such exotic layouts, this is an example where having default in the middle of the switch block makes some sense:

switch( dwSomeValue )
{
case SOME_CHARTTYPE1:
case SOME_CHARTTYPE2:
case SOME_CHARTTYPE3:
case SOME_CHARTTYPE4:
case SOME_CHARTTYPE5:
{
//
// Some Code...
//
break;
}
default:
OutputDebugString("warning: unexpected value; handling as if of the last block\n");
case SOME_CHARTTYPE6:
case SOME_CHARTTYPE7:
case SOME_CHARTTYPE8:
case SOME_CHARTTYPE9:
case SOME_CHARTTYPE10:
{
//
// Some Other Code...
//
}
}

This construct can help a programmer to detect dangerous defaults while still doing something reasonable with them. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo