 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / March 2008Falling through on switch-cases
Is it possible to make C# fall through in switch statement? I was expecting it was possible, why would we need a "break" otherwise? But apparently, i get errors when i try to do that. -- Regards Konrad Viltersten -------------------------------- sleep - a substitute for coffee for the poor ambition - lack of sense to be lazy > Is it possible to make C# fall through in switch statement? Not like in C, but you can jump to a particular case using "goto case". Eq. > Is it possible to make C# fall through > in switch statement? No. You can have multiple labels for the same block, e.g. case 1: case 2: // Code but you can't fall through with code: case 1: // Code (no break) case 2: // Illegal // Code > I was expecting it was possible, why > would we need a "break" otherwise? But > apparently, i get errors when i try to > do that. The switch statement isn't brilliantly designed, basically. See http://msmvps.com/blogs/jon.skeet/archive/2008/02/05/c-4-part-1- looking-back-at-the-past.aspx for a bit more on this and other mistakes (IMO) in C#.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >> Is it possible to make C# fall through >> in switch statement? [quoted text clipped - 25 lines] > > for a bit more on this and other mistakes (IMO) in C#. Thank you. -- Regards Konrad Viltersten -------------------------------- sleep - a substitute for coffee for the poor ambition - lack of sense to be lazy > http://msmvps.com/blogs/jon.skeet/archive/2008/02/05/c-4-part-1- > looking-back-at-the-past.aspx > > for a bit more on this and other mistakes (IMO) in C#. Surely this one is due to the C/C++-syntax heritage? I agree that braces would have been a better choice. And perhaps ranges, like in Pascal: switch (bla) { case 1..10: doThis(); case 11..30: doThat(); case 31..50: { more than one statement; } default: doDefault(); } SignatureRudy Velthuis http://rvelthuis.de "It is unbecoming for young men to utter maxims." -- Aristotle (384-322 B.C.) > > http://msmvps.com/blogs/jon.skeet/archive/2008/02/05/c-4-part-1- > > looking-back-at-the-past.aspx > > > > for a bit more on this and other mistakes (IMO) in C#. > > Surely this one is due to the C/C++-syntax heritage? Absolutely - it's for historical reasons, but there's no reason it shouldn't have been fixed anyway. They already changed fall-through behaviour... > I agree that > braces would have been a better choice. And perhaps ranges, like in [quoted text clipped - 13 lines] > doDefault(); > } Ranges are a possibility, so long as you can always check that a value falls in only one range. (Easy for built-in numeric types, I guess.) I don't really mind if/else if/else if too much though. I suspect there are further ways of transforming it into a more powerful construct though - Groovy does a reasonable job here. You need to potentially work out ways of coping with multiple matches, of course - first wins, execute all, error etc. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > Ranges are a possibility, so long as you can always check that a > value falls in only one range. The compiler should simply generate a compile error if the ranges overlap, like it does in Pascal. Then, only one range can apply. If you'd allow overlapping ranges, the first match could win. SignatureRudy Velthuis http://rvelthuis.de "Ah well, then I suppose I shall have to die beyond my means." -- Oscar Wilde, dying words > > Ranges are a possibility, so long as you can always check that a > > value falls in only one range. > > The compiler should simply generate a compile error if the ranges > overlap, like it does in Pascal. Then, only one range can apply. If > you'd allow overlapping ranges, the first match could win. Yes - as I say, it's easy enough to tell for the built-in numeric types. There may be other types where it's not so obvious though. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >>> Ranges are a possibility, so long as you can always check that a >>> value falls in only one range. [quoted text clipped - 5 lines] > Yes - as I say, it's easy enough to tell for the built-in numeric > types. There may be other types where it's not so obvious though. switch is only allowed on built in integral types and string anyway > >>> Ranges are a possibility, so long as you can always check that a > >>> value falls in only one range. [quoted text clipped - 7 lines] > > switch is only allowed on built in integral types and string anyway Well yes, at the moment - but if we're considering possible changes, we should consider the possibility of a more flexible switch. It really goes back to what the point of switch is. If it's to use a lookup to avoid a series of if/else statements for performance reasons, I'm not sure its place is really deserved in C#. If its purpose is to find one matching piece of code from a number of options, there are ways it could be significantly more flexible. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >> >>> Ranges are a possibility, so long as you can always check that a >> >>> value falls in only one range. [quoted text clipped - 17 lines] > If its purpose is to find one matching piece of code from a number of > options, there are ways it could be significantly more flexible. As a newbie/amateur, I was disappointed with both case statements and enums in C#; both are weaker than what I expected. (Almost everything else was way better than I expected!). As I understand it, I have to write . . . thisday = (int) dayofweek.Sunday . . . switch (thisday); {case (int) dayofweek.Sunday: dostuff();break; case (int) dayofweek.Monday: dostuff(); break; . .} What I was hoping for was: thisday=Sunday; switch (thisday); {case Sunday: dostuff(); break; case Monday: dostuff(); break;} Or even: switch(thisday); {case Sunday: dostuff(); break; case Monday..Friday: dostuff(); break; case Saturday: dostuff(); break;} The continual need to cast back to integers reduces the readability of the code. Also, as someone else pointed out, the ++ operator for enums should loop. If you have a statement: thisday++; and thisday was (int)dayofweek.Saturday, it returns what in reality is an out-of-range enum (as there is no day of the week after Saturday). What I think would have been more useful is thisday++ being equivalent to thisday++; if (thisday>(int)dayofweek.Saturday) thisday=(int) dayofweek.Sunday; or even better thisday++; if (thisday>Saturday) thisday=Sunday; Its probably too late to change this and keep backwards compatibility, so I think C# is stuck with ++ working for enums as it does for integers. As somebody else pointed out, Pascal (now 30 years old) had user defined types which work a little like enums, but in a more readable, maintainable and intuitive form. > As a newbie/amateur, I was disappointed with both case statements and enums > in C#; both are weaker than what I expected. (Almost everything else was way > better than I expected!). I agree with you in general, but it's not quite as bad as you think. > As I understand it, I have to write > [quoted text clipped - 11 lines] > . > .} It's not as bad as that... > What I was hoping for was: > [quoted text clipped - 3 lines] > {case Sunday: dostuff(); break; > case Monday: dostuff(); break;} ... but it's not as good as that. You can write: thisday = DayOfWeek.Sunday; switch (thisday) { case DayOfWeek.Sunday: doStuff(); break; case DayOfWeek.Monday: doStuff(); break; } > The continual need to cast back to integers reduces the readability of the > code. Fortunately it's not there. > Also, as someone else pointed out, the ++ operator for enums should loop. If > you have a statement: [quoted text clipped - 3 lines] > and thisday was (int)dayofweek.Saturday, it returns what in reality is an > out-of-range enum (as there is no day of the week after Saturday). Well, it's more complicated than that. Enums don't *always* represent simple values like that. Sometimes there are gaps, sometimes they're just the "better known" values in a set (e.g. HTTP status codes). Then there are flags enums... It could certainly all be handled better with a lot of careful thought, but it's not quite as simple as is being made out. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >>>> Ranges are a possibility, so long as you can always check that a >>>> value falls in only one range. [quoted text clipped - 7 lines] > > switch is only allowed on built in integral types and string anyway Err.. that should have said integral types (built in or enum) and string. Enums are internally represented as one of the built-in integral types. >> Is it possible to make C# fall through >> in switch statement? [quoted text clipped - 11 lines] > case 2: // Illegal > // Code This is one of the very few times I've seen Jon wrong. You *can* fall through, you just have to make it explicit using "goto case" as Paul has already mentioned. I think that the way C# chose to handle this is very well designed, you still have all the flexibility of C, but without the hidden trap. The compiler message could be a little better though, it should mention your various options (break, return, throw, goto, goto case, and sometimes continue, if you happen to be inside a loop). > >> Is it possible to make C# fall through > >> in switch statement? [quoted text clipped - 21 lines] > various options (break, return, throw, goto, goto case, and sometimes > continue, if you happen to be inside a loop). I'd argue that that isn't really fall through - it's an explicit movement. To me, "fall through" implies dropping off the bottom of one case and into the next implicitly - which isn't allowed. However, that's sophistry to some extent. You're right that I had completely forgotten about it - probably never having used it myself. The sad thing is, I remember having completely forgotten about it *last* time this came up too. I'm sure that's meant to be the difference between ignorance and stupidity - ignorance can be cured. Will try to remember for next time :) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >>>> Is it possible to make C# fall through >>>> in switch statement? [quoted text clipped - 31 lines] > *last* time this came up too. I'm sure that's meant to be the > difference between ignorance and stupidity - ignorance can be cured. I think it's the compiler error message that is guilty of ignorance here... time to open an issue with Connect I guess. It turns out that the MSDN documentation for CS0163 is pretty decent and would have helped the OP... but still inaccurate. https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID =333623 > Will try to remember for next time :) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.