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