Control cannot fall through from one case label ('case 115:')

[puzzlecracker]

Well, the point of my fall through was that some of the cases had a
part of common functionality which i inserted in the last case, thus i
cannot just use one case.
<<

In which case you explicitly state that you want to "fall through"

switch (k)
{
    case MyThingKind.One:
        DoSomething();
        goto case MyThingKind.Common;

    case MyThingKind.Two:
        SoSomethingElse();
        goto case MyThingKind.Common;

    case MyThingKind.Common:
        DoSomethingCommon();
        break;

}

You cannot accidentally type that "goto case" statement but you can
accidentally forget to put in a "break", which I often do especially when
changing a NotImplementedException to implementation code.

That's great, I have factored out the common case out instead of
having part of last case.

 

[Nikola Novak]

They could have done that for strings as well, no biggie. <g>

I was thinking of something along the lines of

switch (bla)
{
case 1, 3, 5:
code ...
break;
case 2, 4, 9:
code ...
break;
case 10..30:
code ...
break;
default:
code ...
break;
}

Actually, the more interesting thing would be this:

switch(blah)
{
case 1:
// code
case 2:
// more code
case 3:
// even more code
default:
// still more code!
break;
}

Now it takes gotos and stuff to make it work and it doesn't do much for the
code tidyness. Of course, let's not forget the Duff's device... a thing of
beauty...

Nikola

 

[Ben Voigt [C++ MVP]]

Actually, the more interesting thing would be this:

switch(blah)
{
case 1:
// code
case 2:
// more code
case 3:
// even more code
default:
// still more code!
break;
}

Now it takes gotos and stuff to make it work and it doesn't do much
for the code tidyness. Of course, let's not forget the Duff's
device... a thing of beauty...

but the cases are themselves labels which you can jump to with goto.
Although the code is longer, it is clearer which I think is the prime
requisite for "tidyness".

And Duff's device is great in a few limited circumstances when properly
explained and encapsulated. I've started to think that usually a "goto"
would be preferable (at least in cases where the first iteration doesn't
start at a number of different lines depending on a single variable).

 

[Nikola Novak]

but the cases are themselves labels which you can jump to with goto.
Although the code is longer, it is clearer which I think is the prime
requisite for "tidyness".

And Duff's device is great in a few limited circumstances when properly
explained and encapsulated. I've started to think that usually a "goto"
would be preferable (at least in cases where the first iteration doesn't
start at a number of different lines depending on a single variable).

I think that the fallthrough concept is clearer than jumping to the next
line with "goto".

Besides, the whole purpose of Duff's device is to make the first iteration
start at any one of the lines depending on a single variable. If you wanted
to do that with goto instead of switch, you'd need a really ugly if ...
else if ... else if ... block, or another switch which is quite pointless
because you can just use the Duff's device then.

The only reason I mentioned Duff's device here though, is because its
elegance (as an optimized solution) is obliterated by the use of gotos on
each line.

Nikola

 

[Michael Starberg]

You really never want to go there. I seem to remember reading an online
interview with Anders H where he was asked if C# would get a "with"
statement, he said "No".

Although it was available in Delphi I stopped using it very early on
because bugs could easily creep into your code as a consequence of using
it.

Pete, one of the few things I truly miss in C# is the with-statement.
Especially in C#3 where you got object-initializers, which looks almost the
same, but is so limited in its use.

However, I have also seen/read Anders H say No. Like, NOOOOO!!!!
So, I guess old pascal serfs like me just have to live with that decision.

But I am curious, what makes the with-statement so dangerous that bugs creep
in when you use it?

My number 1 argument for the with-statement is that it brings scope and also
makes intellisense much smarter. Just as with object initializers,
intellisense then only sports the members for the object that you are
working with. I like that.

- Michael Starberg

 

[Rudy Velthuis]

[...]
Doesn't Pascal have some sort of "using" syntax?

You presumably are referring to the "With" statement, which is the
same as in VB.NET.

"Using" has an entirely different meaning. As far as I can recall,
there's no "Using" in Pascal

Correct, although Delphi Prism has such a construct. It is, like you
said, not nearly the same as "with".

--
Rudy Velthuis http://rvelthuis.de

"The cry has been that when war is declared, all opposition
should be hushed. A sentiment more unworthy of a free country
could hardly be propagated." -- William Ellery Channing

 

[Rudy Velthuis]

You really never want to go there. I seem to remember reading an
online interview with Anders H where he was asked if C# would get a
"with" statement, he said "No".

Although it was available in Delphi I stopped using it very early on
because bugs could easily creep into your code as a consequence of
using it.

Indeed. It makes seeing which scope an identifier has extremely hard,
and can even acquire a new meaning if the identifier is used for a new
property or function in one of the items in scope, in a new version of
your code.

In simple Pascal, using only simple structs, it was useful and
constituted an optimization too, but in modern object oriented Pascals,
it is most of the time counter-productive.

 

[Rudy Velthuis]

Pete, one of the few things I truly miss in C# is the with-statement.

I don't. With is, as someone we know from the Delphi world, would say,
the spawn of the devil. I agree with him and with Peter.

 

[Rudy Velthuis]

But note that the limitation of its use ensures that code that uses
that syntax won't break in subtle, undetected ways due to changes
elsewhere in the code later.

Exactly, and that is exactly why "with" is bad. Oh, the ways will be
detected, sooner or later, but they can be very subtle and hard to
find. <g>
--
Rudy Velthuis http://rvelthuis.de

"Some people, when confronted with a problem, think 'I know, I'll
use regular expressions.' Now they have two problems."
-- Jamie Zawinski

 

[Ben Voigt [C++ MVP]]

I think that the fallthrough concept is clearer than jumping to the
next line with "goto".

It's more concise, but definitely not clearer. In C (or C++) the only
indication that execution continues with the next block is the *absence* of
a branch construct (such as break or return) and since 99+% of cases do end
with a branch, my brain tends to add the missing "branch" while you're
reading the code.

Whereas with explicit goto the sequence of execution is abundantly clear. I
suppose there could have been a "fallthrough" keyword equivalent to "goto
case <whatever-comes-next>" or even a designator on the switch block as a
whole to permit silent fallthrough. But I definitely prefer the C# decision
to require the programmer to explicitly request fallthrough -- it's used so
infrequently that a case block without a branch construct is a bug more
often than not.

Besides, the whole purpose of Duff's device is to make the first
iteration start at any one of the lines depending on a single
variable. If you wanted to do that with goto instead of switch, you'd
need a really ugly if ... else if ... else if ... block, or another
switch which is quite pointless because you can just use the Duff's
device then.

Duff's device also allows starting in the middle of the loop on the first
iteration, which is more efficient execution-wise than mid-loop exit
conditions. But so would a plain goto from outside the loop, or a compiler
smart enough to reorder the halves of the loop to eliminate the
unconditional branch at the bottom.

The only reason I mentioned Duff's device here though, is because its
elegance (as an optimized solution) is obliterated by the use of
gotos on each line.

Duff's device isn't possible in C# at all AFAIK, you can't have looping
constructs stretching across multiple cases.