|
Umm...that's not true. A switch will continue to fall through until you get to a break statement or the end of the switch (i.e. the default case.) On the other hand, if/else statements do bail as soon as the first passing conditional is found and the associated code block is executed.
Scott E. Corbett
|
|
|
|
|
Scott Corbett wrote: A switch will continue to fall through until you get to a break statement or the end of the switch (i.e. the default case.)
Not in C# - every case is required to have a terminating statement (break, goto, return or throw).
Unlike C++, C# does not allow execution to continue from one switch section to the next.
...
C# requires the end of switch sections, including the final one, to be unreachable. That is, unlike some other languages, your code may not fall through into the next switch section.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
You're right about the switch case and fall through. Been spending too much time playing with C++ lately. My apologies.
Scott E. Corbett
|
|
|
|
|
I believe a switch is just a calculated jump statement. It doesn't work it's way through all the previous possibilities. Yes. Once calculated, the program goes to the break statement then jumps out appropriately. Switch statements are quite fast. In this case, I don't see advantage either way as an if statement is very simple too.
|
|
|
|
|
Well I kind of assumed you knew how to write a switch.
|
|
|
|
|
The only reason I could think for writing or keeping the code this way would be if enabled became an enumerated type and had more than 2 states.
|
|
|
|
|
In that case - create it as an enumerated type, with two values. You may then expand the enumeration without rewriting the existing code.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
FirstControl.Enabled = !FirstControl.Enabled;
SecondControl.Enabled = !SecondControl.Enabled;
|
|
|
|
|
Couldn't resist:
void EnableFromValue(bool enabled)
{
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled;
...
}
|
|
|
|
|
it is simple :
void EnableFromValue(bool ?enabled)
{
FirstControl.Enabled=enabled.HasValue?enabled.Value:false;
SecondControl.Enabled=enabled.HasValue?enabled.Value:false;
}
|
|
|
|
|
This works for me
FirstControl.Enabled = SecondControl.Enabled = (enabled) ? false : true;
|
|
|
|
|
LOL! I recently went through my company's entire code base to purge out constructs such as "? true : false".
Even more fun were comparisons such as "if (some_int_var == TRUE)". That's great unless, say "TRUE" is defined as 1 and your variable is set to -1.
|
|
|
|
|
Look. this construct is a perfect alternating on/off switch.
I've used it exclusively over past 10 years.
There is no valid reason not to use it, especially if you favor
Clean, concise, easy to understand code.
Different strokes ...
Tony d
|
|
|
|
|
No, "? false : true" is still superfluous. Just use ! (the not operator). It's certainly more concise, and I would argue, even cleaner and easier to understand.
FirstControl.Enabled = SecondControl.Enabled = !enabled;
|
|
|
|
|
Hey Dan love the use of Boolean operators.
Used them extensively in the old mainframe days when storage was measured in megabytes.
When working with 16mb system storage every byte counted. Here's an old trick to save bytes
a *-6, ctr.
Used this in 360/370 mainframes since adding the opcode (numeric value of 1) would save 1 byte.
nice chatting with a knowledgeable tech
|
|
|
|
|
If you are sure that the function argument named enabled is bool forever? If yes than there is no reason for the switch. If chacne to change the argument type is exist so - I would add into the switch
default:
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled;
|
|
|
|
|
Al Chak wrote: If chacne to change the argument type is exist so - I would add into the switch
There's no reason to add a switch statement now just in case the argument type changes in six months.
Add the switch when you need it - ie: when the argument type changes. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
If it is not break-en, don't switch it?
[[Thank you, I'm here all week; try the veal...]]
Chaos.
|
|
|
|
|
well, switch is shorthand for the if--then--else construct.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
They forgot the default clause!  
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
With "simple" booleans, a switch statement is not necessary. But what about "extended" boolenas (i.e. true, false, don_t_know, FILE_NOT_FOUND)? That's where a switch comes in very handy.
|
|
|
|
|
Ever tried to create a generic class which accepts Enum types only? Can be fun!
I have a non-generic class EnumDescConverter and wanted to add a generic version EnumDescConverter<T>. Easy, isn't it? Just write
public class EnumDescConverter<T> : EnumDescConverter where T : Enum
and the error is
Constraint cannot be special class 'System.Enum'
Well, you have to use a different approach. An Enum is a struct which implements IConvertible. Hence you can do
public class EnumDescConverter<T> : EnumDescConverter where T : struct, IConvertible
and then check in the constructor that T is really an enum: if (!enumType.IsEnum) { throw ...}
And now let's do more bad things. 
The non-generic class has a function
public Enum GetEnumValue(string description)
Let's add a generic version in the generic class so that we do not need to cast the return value to the type of the enum in use:
public T GetEnumValue(string description)
And the warning is:
warning CS0108: 'EnumDescConverter<T>.GetEnumValue(string)' hides inherited member 'EnumDescConverter.GetEnumValue(string)'. Use the new keyword if hiding was intended.
A possible solution, but not nice.
If you make the method in the base class virtual, and override it in the generic class, the error is:
'EnumDescConverter<T>.GetEnumValue(string)': return type must be 'System.Enum' to match overridden member 'EnumDescConverter.GetEnumValue(string)'
Hm. Let me change the name of the function, and in its body just call the base class' method and cast the return value (not a nice solution either):
public T GetEnumValueT(string description)
{
return (T)GetEnumValue(description);
}
And the next error arises:
Cannot convert type 'System.Enum' to 'T'
Of course,
return GetEnumValue(description) as T;
doesn't work either because an Enum is not a class:
The type parameter 'T' cannot be used with the 'as' operator because it does not have a class type constraint nor a 'class' constraint
But the problem can be solved by a double-cast:
return (T)((object)GetEnumValue(description));
That's Weird and Wonderful, isn't it? 
|
|
|
|
|
 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
A joke, I know, but that's just crazy! 
You have just been Sharapova'd.
|
|
|
|
|
Fody can do that[^]
The fact that you need a third party IL manipulation library to do this is still a WTF though.
Edit: damn autoincorrect.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
