About switch case statements...

Denis Koroskin 2korden at gmail.com
Mon Nov 16 14:04:50 PST 2009


On Mon, 16 Nov 2009 23:36:38 +0300, Derek Parnell <derek at psych.ward> wrote:

> On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote:
>
>> bearophile wrote:
>>> Don:
>>>
>>>> (providing that empty fall-through case statements remain valid;
>>>> disallowing them would be really annoying).
>>>
>>> What's bad about forcing people to write:
>>> case A, B, C:
>>>
>>> Instead of:
>>> case A:
>>> case B:
>>> case C:
>>> ?
>>>
>>> Bye,
>>> bearophile
>>
>> (1) "case A, B, C:" implies a relationship between A, B, and C, which
>> might not exist. They may have nothing in common.
>> (2) it's an extremely common coding style in C, C++.
>> (3) it's more difficult to read.
>
> (1)  case A:
>      case B:
>      case C:
>    implies that there is no relationship between A,B, and C, but which
> might actually exist. They may have something common.
> (2) it's an extremely common writing style in human languages, thus aids
> readability.
> (3)  case A:
>      case B:
>      case C:
>    is ambiguous. It looks like the coder put in place markers for  
> intended
> code but forgot the code.
>
>

When porting some C++ code to D (okay, it was DMDFE), I had exact same  
issue. There is the following macro defined:

#define CASE_BASIC_TYPES			\
	case TOKwchar: case TOKdchar:		\
	case TOKbit: case TOKbool: case TOKchar:	\
	case TOKint8: case TOKuns8:		\
	case TOKint16: case TOKuns16:		\
	case TOKint32: case TOKuns32:		\
	case TOKint64: case TOKuns64:		\
	case TOKfloat32: case TOKfloat64: case TOKfloat80:		\
	case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:	\
	case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:	\
	case TOKvoid

and if was used (and got translated to D) as follows:

switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     CASE_BASIC_TYPES:
}

Did you noticed it already? It is a valid C code *but* has different  
semantics! In D, CASE_BASIC_TYPES is merely a label, and it does just  
nothing. Needless to say the code compiled successfully, but produced  
weird error messages at run-time.

BTW, if a macro was declared as

#define BASIC_TYPES			\
	     TOKwchar: case TOKdchar:		\
	case TOKbit: case TOKbool: case TOKchar:	\
	case TOKint8: case TOKuns8:		\
	case TOKint16: case TOKuns16:		\
	case TOKint32: case TOKuns32:		\
	case TOKint64: case TOKuns64:		\
	case TOKfloat32: case TOKfloat64: case TOKfloat80:		\
	case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:	\
	case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:	\
	case TOKvoid

(note an absence of the first case) then it would cause compile-time error  
instead of run-time bugs. Usage:

switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     case BASIC_TYPES:
}



More information about the Digitalmars-d mailing list