Switch statement help

V

VK

Lee said:
It's a very handy way to identify people who don't know how to
read a manual. Programmers should avoid guessing how features
work.

As it was pointed out already, it is not how do things work - it's
about how the logic works.

"If *this* is True than do this, otherwise if *that* is true then do
that, if nothing is true then do *this thing* "

But you have to remember that there is *one* exception implementing a
perverted logic: "if this is true, then anything else is also true even
if it's false".

Easy to remember - but also easy to forget because 99.99% of time you
are still dealing with the normal machine logic.

One of things to pin near of your monitor I guess - or simply avoid to
use :)
 
L

Lee

VK said:
As it was pointed out already, it is not how do things work - it's
about how the logic works.

"If *this* is True than do this, otherwise if *that* is true then do
that, if nothing is true then do *this thing* "

But you have to remember that there is *one* exception implementing a
perverted logic: "if this is true, then anything else is also true even
if it's false".

The switch is NOT an if then else statement.
It's a completely different construct.

If you're unable to get your brain around that concept, then I
suppose it might be horribly confusing for you, but you probably
shouldn't be trying to write code. Or drive. Or vote. Please
tell me you don't vote.
 
L

Lasse Reichstein Nielsen

Lee said:
Lasse Reichstein Nielsen said:


It's a very handy way to identify people who don't know how to
read a manual. Programmers should avoid guessing how features
work.

Absolutely. But even the ones who do know can forget, and the more
illogical a feature is, and the more it differs from other languages
that the programmer also use regularly, the more will forget it.

But while we are at guessing, fallthrough in a switch fails the "least
surprise" test of good design. If shown a switch in any other syntax,
if I should make a guess, I would not guess that there was fallthrough.

/L
 
R

Richard Cornford

Lasse said:
Absolutely. But even the ones who do know can forget, and the
more illogical a feature is, and the more it differs from other
languages that the programmer also use regularly, the more will
forget it.

But while we are at guessing, fallthrough in a switch fails the
"least surprise" test of good design. If shown a switch in any
other syntax, if I should make a guess, I would not guess that
there was fallthrough.

As you have pointed out that switch was adopted from C, and had
fall-through originally, the design error may have been retaining the
same keyword for versions that did not have fall-through.

Richard.
 
L

Lee

Lasse Reichstein Nielsen said:
Absolutely. But even the ones who do know can forget, and the more
illogical a feature is, and the more it differs from other languages
that the programmer also use regularly, the more will forget it.

So you would have all flow-control constructs work identically
just so it's easier to remember how they work?
But while we are at guessing, fallthrough in a switch fails the "least
surprise" test of good design. If shown a switch in any other syntax,
if I should make a guess, I would not guess that there was fallthrough.

That's because you're thinking in terms of "if then else".
The switch determines the entry point into a block of statements.
When you think about it that way, fallthrough is the expected
behavior.
 
L

Lasse Reichstein Nielsen

Lee said:
That's because you're thinking in terms of "if then else".

Absolutely. That's the way similar constructs are described in other
languages like Pascal, Scheme, Ada, and even in Fortran which predates
C.

<URL:http://www.xploiter.com/mirrors/pascal/pas026.htm>
<URL:http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.2.1>
<URL:http://www.adaic.org/standards/95lrm/html/RM-5-4.html>
The switch determines the entry point into a block of statements.
When you think about it that way, fallthrough is the expected
behavior.

You could say that C doesn't have a multiway conditional like the
languages above, and instead has a computed goto statement called
"switch". You would probably technically be right too

It's just that the multiway conditional is such a useful construct, as
its general adaption in pretty much any other language family
suggests, that you *will* try to simulate it with the nearest
equivalent in the language, especially when switch is so close. And
that was also the intention of the switch statment.

Quoting from "The Ansi C Languge, 2ed" (page 59):

"Falling trough from one case to another is not robust, being prone to
disintegration when the program is modified. With the exception of
multiple labels for a single computation, fall-throughs should be used
sparingly, and commented."


Again, C's switch is from a time when expressive power was more
important than readability or even maintainability. You could do some
things with fallthorough that you can't easily do without (without
duplicating code). But I would still much rather have had a continue
statement to mark the fallthrough than the absence of a break.

We just have to live with it. We don't have to like it :)

/L
 
L

Lasse Reichstein Nielsen

Kevin Newman said:
Since it is argued that there is merit in having fall through
sometimes, I wonder if the fix could be something like to remove the
necessity of the break keyword to prevent fall through, but add the
continue keyword to enable it (of course this would break existing
code that uses fall through - so it's just theoretical).

Scaringly, I just suggested the exact same thing in another post,
before reading it here. It kindof suggests that it would be the
obvious solution :)

/L
 
V

VK

Kevin said:
It's fun when that happens. :)

And of course no credits to who really said it first (oh well - as
usual :)

See my 2nd post in this thread:
<quote>
A perfect case of reversed logic for me. That would have some sense
maybe to have a flag to "continue" execution of underlaying branches -
but not a current annoyance twist.
</quote>

A regular destiny of a genius - he does the things, but others are
benefiting of it.

:-D
 
X

X l e c t r i c

VK wrote:

"And of course no credits to who really said it first (oh well - as
usual :)

See my 2nd post in this thread:
<quote>
A perfect case of reversed logic for me. That would have some sense
maybe to have a flag to "continue" execution of underlaying branches -
but not a current annoyance twist.
</quote>

A regular destiny of a genius - he does the things, but others are
benefiting of it.
:-D"

Be honest VK. You read that in Lee's manual, didn't you ?
 

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

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top