case labels

S

sandeep

Hi,

why general integer expressions are not allowed in case labels in
switch statements..????
 
T

Tom St Denis

Hi,

why general integer expressions are not allowed in case labels in
switch statements..????

The spec says so? I think originally most switch tables were done
literally as a lookup table which is why the expression had to be
static [e.g. can be stored in code].

Tom
 
P

Peter Nilsson

sandeep said:
why general integer expressions are not allowed in case
labels in switch statements..????

A better question is why should they be allowed?

Of course, there are some (few) advantages, but there are many
disadvanteges to implementors. Note that implementors are already
quite free to offer it as an extension. The fact that few (if any)
do shows that there's not much call for it. [As well as there
being some subtle cases to consider that stop most implementors
wasting too much development time on it.]
 
S

sandeep

Peter said:
sandeep said:
why general integer expressions are not allowed in case labels in
switch statements..????

A better question is why should they be allowed?

Of course, there are some (few) advantages, but there are many
disadvanteges to implementors. Note that implementors are already quite
free to offer it as an extension. The fact that few (if any) do shows
that there's not much call for it. [As well as there being some subtle
cases to consider that stop most implementors wasting too much
development time on it.]

The real elaborate question i wanted to ask was

why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?
 
T

Tom St Denis

The real elaborate question i wanted to ask was

why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?

Do your own homework? Why not compile some code and see how compilers
implement the switch statement.

Tom
 
B

bart.c

sandeep said:
Peter said:
sandeep said:
why general integer expressions are not allowed in case labels in
switch statements..????

A better question is why should they be allowed?

Of course, there are some (few) advantages, but there are many
disadvanteges to implementors. Note that implementors are already quite
free to offer it as an extension. The fact that few (if any) do shows
that there's not much call for it. [As well as there being some subtle
cases to consider that stop most implementors wasting too much
development time on it.]

The real elaborate question i wanted to ask was

why are constant integer expressions required in case labels of the
switch statement?

Each expression needs to be unique. You can't ensure that with runtime
expressions:

int a,x,y; ...

switch (a) {
case x:...
case y:...

What should happen here when a==x==y?
what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?

What's this, an exam paper?
 
K

Kenny McCormack

Each expression needs to be unique. You can't ensure that with runtime
expressions:[/QUOTE]

I agree that there's not much point in implementing this in a legacy
language such as C. But other, vaguely C-like, languages have done it.
int a,x,y; ...

switch (a) {
case x:...
case y:...

What should happen here when a==x==y?

The first hit, of course.
Which implies, of course, that it be implemented as (something like) a
series of if-then-else-if-then-else... and not as a jump table.
What's this, an exam paper?

Or just a literate poster.

This, of course, illustates well one of Spinny's points. That if
a poster uses formal, correct language, it gets tagged as "homework" - a
grevious sin. Not macho.

--
No, I haven't, that's why I'm asking questions. If you won't help me,
why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.
 
T

Tim Streater

Each expression needs to be unique. You can't ensure that with runtime
expressions:

I agree that there's not much point in implementing this in a legacy
language such as C. But other, vaguely C-like, languages have done it.
int a,x,y; ...

switch (a) {
case x:...
case y:...

What should happen here when a==x==y?

The first hit, of course.
Which implies, of course, that it be implemented as (something like) a
series of if-then-else-if-then-else... and not as a jump table.
What's this, an exam paper?

Or just a literate poster.[/QUOTE]

"discuss both user convenience and implementation aspects?"

Is this a question - if so what is it? Or was there a missing "Would
you" or "Would you please" which could have made it a polite request?

Or was the question mark accidental, in which case this just comes over
as imperative.

Perhaps you'd like to clear up the point for us.
This, of course, illustates well one of Spinny's points. That if
a poster uses formal, correct language, it gets tagged as "homework"

That's just it though. Few of the "do my homework" posters have used
formal, correct language. Or hadn't you noticed?
 
T

Tom St Denis

I agree that there's not much point in implementing this in a legacy
language such as C.  But other, vaguely C-like, languages have done it.

They're called exceptions. C++ or Java is down the hall.
The first hit, of course.
Which implies, of course, that it be implemented as (something like) a
series of if-then-else-if-then-else... and not as a jump table.

Except the C spec does not guarantee the order of evaluation (the
execution must follow the statements in order but how it performs the
case statement evaluations is not defined). So you end up with UB.
Or just a literate poster.

This, of course, illustates well one of Spinny's points.  That if
a poster uses formal, correct language, it gets tagged as "homework" - a
grevious sin.  Not macho.

It was clearly homework. Why else would he ask for an essay on the
"pros" and "cons." Specifically stating the instruction "discuss ..."
smacks of homework.

Tom
 
B

bart.c

Kenny McCormack said:
...

I agree that there's not much point in implementing this in a legacy
language such as C. But other, vaguely C-like, languages have done it.

(Yes, I implement this, but I chose to have a separate statement that could
have non-const (and non-int) case expressions, allowing the normal switch
statement to remain streamlined.)
The first hit, of course.
Which implies, of course, that it be implemented as (something like) a
series of if-then-else-if-then-else... and not as a jump table.

That would change of the nature of switch statements, where usually the
order of the labels is not important.

And because of the unique way C's case labels work (where they can be
embedded inside statements within the switch block), it would be difficult
to map to a linear if-then-else chain.
Or just a literate poster.

No-one uses phrases such as "discuss both user convenience..." in normal
writing or speaking. Not unless he's a professor drafting exam questions.
 
J

James Dow Allen

The first hit, of course.

Or perhaps, take *all* applicable hits sequentially ...
"of course."
(*Which* "hits" apply will perhaps change each call,
since the cases are *variable*.)

But *I* don't find such complex "use-friendly" switch
handling to be ... er ... friendly.

C's forte is its *SIMPLICITY* for heaven's sake!
Invent a "friendlier" (and probably more error-prone)
language if you wish, but don't call it C.
Or just a literate poster.

It appears to me likely to be a rephrasing of homework
(though from a teacher more advanced than we usually
see here). YMMV.

James
 
K

Keith Thompson

Tom St Denis said:
Do your own homework? Why not compile some code and see how compilers
implement the switch statement.

How would that answer the question?

Most relatively compact switch statements are probably implemented with
a jump table, but this:

switch (n) {
case 0: /* ... */
case UINT_MAX: /* ... */
default: /* ... */
}

almost certainly isn't.

It's not an entirely unreasonable question; the language *could* have
permitted non-constant case labels. Some issues would have to be
resolved:
What happens when more than one case matches?
If the label expressions have side effects, which ones are
evaluated?
but I see no insoluble problems.

I'd say the reasons are mostly historical, though there are still
good reasons to disallow non-constant expressions.
 
N

Nick Keighley

I agree that there's not much point in implementing [non constant switch labels]
in a legacy language such as C.

but more modern languages like Lisp have had it for ages

 But other, vaguely C-like, languages have done it.

They're called exceptions.  C++ or Java is down the hall.

I don't think they are.

Except the C spec does not guarantee the order of evaluation (the
execution must follow the statements in order but how it performs the
case statement evaluations is not defined).  So you end up with UB.

it could quite easily specify the order. If you change a language you
aren't required to make completely stupid decisions.

<snip>

--
****Can anyone find the error
Yes:
Error on line 0: Lazy programmer.
(comp.lang.c++)
 
K

Kenny McCormack

Nick Keighley said:
On Jun 1, 9:33 am, (e-mail address removed) (Kenny McCormack) wrote:

I agree that there's not much point in implementing [non constant switch
labels]
in a legacy language such as C.

but more modern languages like Lisp have had it for ages

Why do you describe Lisp as more modern than C?

Yes, there's a bit of irony there, since we all know that Lisp was
invented in the 60s, while C came from the 70s. But the fact is that
Lisp is a dynamic, constantly evolving language, while C is, by design, a
static, legacy language.
 
T

Tim Streater

Nick Keighley said:
On Jun 1, 9:33 am, (e-mail address removed) (Kenny McCormack) wrote:

I agree that there's not much point in implementing [non constant
switch
labels]
in a legacy language such as C.

but more modern languages like Lisp have had it for ages

Why do you describe Lisp as more modern than C?

Yes, there's a bit of irony there, since we all know that Lisp was
invented in the 60s, while C came from the 70s. But the fact is that
Lisp is a dynamic, constantly evolving language, while C is, by design, a
static, legacy language.

Static it may be but legacy it aint.
 
K

Kenny McCormack

On Jun 1, 9:33 am, (e-mail address removed) (Kenny McCormack) wrote:

I agree that there's not much point in implementing [non constant
switch
labels]
in a legacy language such as C.

but more modern languages like Lisp have had it for ages

Why do you describe Lisp as more modern than C?

Yes, there's a bit of irony there, since we all know that Lisp was
invented in the 60s, while C came from the 70s. But the fact is that
Lisp is a dynamic, constantly evolving language, while C is, by design, a
static, legacy language.

Static it may be but legacy it aint.

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legacy-is-not-a-pejorative.html

The question is, of course, if it is not a pejorative, then what is it?
One could reasonably ask why I felt the need to include the word in my
post above. What did it add that "static" did not already convey?

These are good questions, to which I don't have good answers. The text
at the above URL implies that "legacy" means "good" - i.e., that "they
don't make 'em like that anymore". There's probably a lot of truth to
that.

Of course, we all know that, like every other industry, the software
industry cannot survive without constantly re-making itself - by repeatedly
convincing us all that we need the newest, latest, bestest thing. I
particularly liked Jacob's comments to this effect - that fashion drives
(and keeps economically healthy) the software industry just as it drives
the clothing industry. That Jacob in fact lives in Paris, of course,
makes his comments just so delicious.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...
 
T

Tim Streater

On Jun 1, 9:33 am, (e-mail address removed) (Kenny McCormack)
wrote:

I agree that there's not much point in implementing [non constant
switch
labels]
in a legacy language such as C.

but more modern languages like Lisp have had it for ages

Why do you describe Lisp as more modern than C?

Yes, there's a bit of irony there, since we all know that Lisp was
invented in the 60s, while C came from the 70s. But the fact is that
Lisp is a dynamic, constantly evolving language, while C is, by design, a
static, legacy language.

Static it may be but legacy it aint.

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legacy-is-not-a-pejor
ative.html

The question is, of course, if it is not a pejorative, then what is it?
One could reasonably ask why I felt the need to include the word in my
post above. What did it add that "static" did not already convey?

These are good questions, to which I don't have good answers. The text
at the above URL implies that "legacy" means "good" - i.e., that "they
don't make 'em like that anymore". There's probably a lot of truth to
that.

Fair enough. I agree that "legacy" shouldn't imply "out-of-date"
although too often it does.
Of course, we all know that, like every other industry, the software
industry cannot survive without constantly re-making itself - by repeatedly
convincing us all that we need the newest, latest, bestest thing. I
particularly liked Jacob's comments to this effect - that fashion drives
(and keeps economically healthy) the software industry just as it drives
the clothing industry. That Jacob in fact lives in Paris, of course,
makes his comments just so delicious.

True, but I feel it's up to us to pick and choose. 20 years ago the
requirements for what *I* was doing involved a language that supported
recursion and reentrancy, had a simple interface to assembler so we
could access the host systems' (VAX/VMS and IBM's VM/CMS) timer and I/O
subsystems, and for which compliers existed for the two hosts in
question. So C was a good choice for that.

Nowadays I want a cheap way to get a GUI interface for the user, so I
drive a web browser with JavaScript, and use AJAX to access PHP scripts
to do the backend work. I can't be arsed to learn how to do that with C.
A bit heavy perhaps, since I need to be running apache as well, but it's
all software that comes with the OS.

OTOH, if someone said (unlikely) here's a million quid to write xyz bit
of driver or kernel software, I'd prolly go off and learn Objective C or
whatever it is that Apple uses.

So the newest latest and bestest is not always a bad thing.
 
T

Tim Rentsch

Peter Nilsson said:
sandeep said:
why general integer expressions are not allowed in case
labels in switch statements..????

A better question is why should they be allowed?

Of course, there are some (few) advantages, but there are many
disadvanteges to implementors. Note that implementors are already
quite free to offer it as an extension. [snip]

Kind of. They are free to offer general-integer-expression case
labels only if a diagnostic is issued when a case label isn't an
integer constant expression. Extensions are allowed to accept
other forms of integer constant expressions, but this permission
has limits; they must be evaluable at compile time, for example,
and they (mostly) can't use comma operators or function calls
(among others). So non-constant-expression case labels can be
offered as an extension only in the sense that _any_ constraint
violation can be given a diagnostic message and assigned any
semantics whatsoever.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top