|
|
|
date: Wed, 20 Aug 2008 06:38:25 -0700,
group: microsoft.public.dotnet.framework
back
RE: switch language extension
Hi Mark,
If I have understood you completely, you are suggesting adding the second
parameter to the C# "switch" keyword.
First, this second parameter only applies to the string object type, so the
"switch" keyword must support variable parameters list. I am not a
compilation expert, but I did not see the cases that C# language keyword
supports variable parameter list. So I suspect if this can be supported by
"switch" keyword.
Second, if this feature can be supported, it should be a C# language
extension which should not be part of the Command Language
Specification(CLS). It will become the Microsoft specific extension.
Anyway, the best way to feedback you suggestion is using the feedback
center below:
https://connect.microsoft.com/VisualStudio?wa=wsignin1.0
Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
date: Thu, 21 Aug 2008 03:36:05 GMT
author: (Jeffrey Tan[MSFT])
Re: switch language extension
Well, personally I think the appeal of case-insensativity is vastly
overblown, but it often comes up on serialization boundaries, messaging
systems, and configuration files. I've inherited a code base obsessed with
case-insensativity so I see the original pattern everywhere.
> - IMO this is a micro-optimization that really doesn't worth in most cases
> - if you had a real life huge loop a best practice would be to normalize the
> value outside of the loop not in each iteration (IMO you ran the ToLower in
> each ean every loop)
Yes, but time testing often means you replicate what the code does and wrap
a big loop around it. You can't optimize the loop invariants outside the
loop because that defeats the purpose of testing one pattern against the
other.
> IMO all this remains quite theoricall for now. I would much prefer a real
> life scenario...
>
> Also I'm not really sure to understand how it could help. If you tell C# to
> ignore case then behind the scene the code still has additional work to do
> something similar to what you have done explicitely...
The question is what "additional work" gets done. The String.ToLower() call
*guarantees* at least 1 full pass through the input and the possible creation
of a copy object which puts additional load on the garbage collection.
Depending on the app circumstances the extra object in the pool is 10x the
work.
Another way to replace the
switch (input.ToLower())
{...}
pattern is to use
if (input.Equals("1stcase", StringComparison.OrdinalIgnoreCase))
...
else if (input.Equal("2ndcase", StringComparison.OrdinalIgnoreCase))
...
etc.
Aside from the verbosity, with the 2nd pattern you don't make another copy
of the input and you keep all the advantages in comparison (length test,
object identity test). The only "additional work" in the 2nd pattern is one
character case test when you haven't matched.
But the 2nd pattern loses the flexibility of switch for optimization because
the ifs have to be executed in order.
Looking at some sample switch optimizations in ildasm, it seems that for
string operands with > 10 cases, the compiler builds a Dictionary<string,
int> jump vector in memory, so you get the benefit of hash table lookup
speeds.
If we had a comparitor option operand on switch, it could build a
new Dictionary<string, int>(StringComparer.OrdinalIgnoreCase)
instead.
That way you get the switch optimization and case insensitivity without the
hit ToLower() brings.
Yes, you could consider this a micro optimization, but MS puts out other
whitepapers suggesting
if (str.Length == 0)
instead of
if (str == "")
and advising how many concatenations you should do before using StringBuilder.
Mark
date: Mon, 25 Aug 2008 09:20:00 -0700
author: Mark am
|
|
