S
sandeep
Hi,
why general integer expressions are not allowed in case labels in
switch statements..????
why general integer expressions are not allowed in case labels in
switch statements..????
Hi,
why general integer expressions are not allowed in case labels in
switch statements..????
sandeep said:why general integer expressions are not allowed in case
labels in switch statements..????
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?
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?
what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?
int a,x,y; ...
switch (a) {
case x:...
case y:...
What should happen here when a==x==y?
What's this, an exam paper?
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.
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's this, an exam paper?
This, of course, illustates well one of Spinny's points. That if
a poster uses formal, correct language, it gets tagged as "homework"
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.
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.
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.
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.
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.
Or just a literate poster.
The first hit, of course.
Or just a literate poster.
Tom St Denis said:Do your own homework? Why not compile some code and see how compilers
implement the switch statement.
why general integer expressions are not allowed in case labels in
switch statements..????
I agree that there's not much point in implementing [non constant switch labels]
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.
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.
Yes:****Can anyone find the error
Nick Keighley said: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
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?
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.
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.
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.
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.
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]
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.