|
|
Up |
|
|
  |
Author: aarklonaarklon Date: Mar 27, 2008 21:59
Hi,
why general integer expressions are not allowed in case labels in
switch statements..????
|
| |
|
| | 68 Comments |
|
  |
Author: Ian CollinsIan Collins Date: Mar 27, 2008 22:03
> Hi,
>
> why general integer expressions are not allowed in case labels in
> switch statements..????
Because they must be compile time constants.
--
Ian Collins.
|
| |
|
| | no comments |
|
  |
Author: sumsinsumsin Date: Mar 27, 2008 22:41
On Mar 28, 10:03 am, Ian Collins hotmail.com> wrote:
>> Hi,
>
>> why general integer expressions are not allowed in case labels in
>> switch statements..????
>
> Because they must be compile time constants.
>
> --
> Ian Collins.
Could you elaborate this concept?
|
| |
| no comments |
|
  |
Author: Ian CollinsIan Collins Date: Mar 27, 2008 23:18
sumsin wrote:
> On Mar 28, 10:03 am, Ian Collins hotmail.com> wrote:
>>> Hi,
>>> why general integer expressions are not allowed in case labels in
>>> switch statements..????
>> Because they must be compile time constants.
>>
*Please* don't quote signatures.
>
> Could you elaborate this concept?
The language requires case labels to be compile time constants. There
really isn't a concept to elaborate on.
--
Ian Collins.
|
| |
| no comments |
|
  |
Author: Keith ThompsonKeith Thompson Date: Mar 27, 2008 23:33
Ian Collins hotmail.com> writes:
> sumsin wrote:
>> On Mar 28, 10:03 am, Ian Collins hotmail.com> wrote:
>>>> Hi,
>>>> why general integer expressions are not allowed in case labels in
>>>> switch statements..????
>>> Because they must be compile time constants.
>>>
> *Please* don't quote signatures.
>>
>> Could you elaborate this concept?
>
> The language requires case labels to be compile time constants. There
> really isn't a concept to elaborate on.
Unless you want to know *why* the standard imposes this requirement.
|
| Show full article (1.43Kb) |
| no comments |
|
  |
Author: user923005user923005 Date: Mar 27, 2008 23:59
On Mar 27, 11:33Â pm, Keith Thompson mib.org> wrote:
> Ian Collins hotmail.com> writes:
>> sumsin wrote:
>>> On Mar 28, 10:03 am, Ian Collins hotmail.com> wrote:
>>>>> Hi,
>>>>> why general integer expressions are not allowed in case labels in
>>>>> switch statements..????
>>>> Because they must be compile time constants.
>
>> *Please* don't quote signatures.
>
>>> Could you elaborate this concept?
>
>> The language requires case labels to be compile time constants. Â There
>> really isn't a concept to elaborate on.
>
> Unless you want to know *why* the standard imposes this requirement.
>
> The code generated for a switch statement is typically a static jump ...
|
| Show full article (1.49Kb) |
| no comments |
|
  |
Author: BartcBartc Date: Mar 28, 2008 06:20
> Hi,
>
> why general integer expressions are not allowed in case labels in
> switch statements..????
There's no reason why switch expressions can't be any (identical) type, as
Keith has suggested.
If they are all constant integers, then fine generate a jump table.
Otherwise generate appropriate if-statements. This is very easy at a time
when C compilers are so super-sophisticated they can almost bake bread too.
But the people responsible for new C standards have decided to keep this
area of the language (control statements in general) at a primitive level.
So the programmer has to code his logic in a less expressive manner.
--
Bart
|
| |
| no comments |
|
  |
Author: Eric SosmanEric Sosman Date: Mar 28, 2008 06:35
Bartc wrote:
>
> There's no reason why switch expressions can't be any (identical) type, as
> Keith has suggested.
>
> If they are all constant integers, then fine generate a jump table.
> Otherwise generate appropriate if-statements. This is very easy at a time
> when C compilers are so super-sophisticated they can almost bake bread too.
>
> But the people responsible for new C standards have decided to keep this
> area of the language (control statements in general) at a primitive level.
>
> So the programmer has to code his logic in a less expressive manner.
If you switch on a double, with double case labels,
what's the matching criterion? Exact equality is seldom
useful, and it's not clear how a suitable "fuzz factor"
should be provided. Case label ranges, perhaps, but what
to do with infinities and NaNs? (Can a NaN be matched
at all, other than by the default case?)
|
| Show full article (1.83Kb) |
| no comments |
|
  |
Author: BartcBartc Date: Mar 28, 2008 06:58
"Eric Sosman" wrote in message
news:r62dnXScdbSgaXHanZ2dnUVZ_j6dnZ2d@comcast.com...
> Bartc wrote:
>>
>> There's no reason why switch expressions can't be any (identical) type,
>> as Keith has suggested.
>>
>> If they are all constant integers, then fine generate a jump table.
>> Otherwise generate appropriate if-statements. This is very easy at a time
>> when C compilers are so super-sophisticated they can almost bake bread
>> too.
>>
>> But the people responsible for new C standards have decided to keep this
>> area of the language (control statements in general) at a primitive
>> level.
>>
>> So the programmer has to code his logic in a less expressive manner.
>
> If you switch on a double, with double case labels,
> what's the matching criterion? ...
|
| Show full article (2.15Kb) |
| no comments |
|
  |
|
|
  |
Author: Chris DollinChris Dollin Date: Mar 28, 2008 07:00
Eric Sosman wrote:
(fx:dreaming)
> If you switch on a struct-valued expression, what's
> the matching criterion?
struct_Foo_switch_equality
( struct Foo *switched, struct Foo *cased );
struct_Foo_hash_value
( struct Foo *foo );
> If you switch on a `char*', should the matching
> criterion be strcmp()? Or caseInsensitiveStrcmp()? Or
> allWhiteSpaceCountsAsIdenticalStrcmp()?
strcmp. If the user wants something else, they can canonise
their switched string first. (And I'm imagining a `strhash`.)
I grant that an implementation is more convincing than a handwave is.
Getting non-unfortunate performance might be more of a problem than
mere semantics. (Hence the hashes.)
--
"Its flagships were suns, its smallest vessels, /The City and the Stars/
planets."
|
| Show full article (0.96Kb) |
| no comments |
|
|
|
|