22

Why does the compiler say "a constant value is required" for the first case...the second case works fine...

switch (definingGroup)
{
    case Properties.Settings.Default.OU_HomeOffice:  
        //do something  
        break;
    case "OU=Home Office":  
        //do something
        break;
    default:
        break;
 }

also tried...

switch (definingGroup)
{
    case Properties.Settings.Default.OU_HomeOffice.ToString():  
        //do something
        break;
    case "OU=Home Office":
        //do something
        break;
    default:
        break;
 }

...same error

Here's the Properties.Setting code

[global::System.Configuration.ApplicationScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("OU=Home Office")]
public string OU_HomeOffice {
    get {
        return ((string)(this["OU_HomeOffice"]));
    }
}
Wai Ha Lee
  • 8,598
  • 83
  • 57
  • 92
w4ik
  • 1,276
  • 2
  • 19
  • 33
  • see question: http://stackoverflow.com/questions/44905/c-switch-statement-limitations-why – Ray Oct 16 '09 at 06:49

3 Answers3

41

Properties.Settings.Default.OU_HomeOffice isn't a constant string - something known at compile time. The C# switch statement requires that every case is a compile-time constant.

(Apart from anything else, that's the only way it can know that there won't be any duplicates.)

See section 8.7.2 of the C# 3.0 spec for more details.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 3
    Jon - tell me you didn't come up with "section 8.7.2 of the C# 3.0 spec" off the top of your head. Sheesh...and you had the first answer as well. – Mark Brittingham Jan 21 '09 at 19:19
  • 1
    No, don't worry - I did have to look it up. That was actually in an edit, too - but I suspect SO doesn't bother showing it as an edit if it's close enough to the original post. – Jon Skeet Jan 21 '09 at 19:22
  • 1
    @Shimmy: What exactly is sucky behaviour? – Jon Skeet Dec 11 '11 at 17:59
  • That it must be const. I'm a VB.NET user where the switch statement is made very flexible. – Shimmy Weitzhandler Dec 11 '11 at 20:45
  • @Shimmy: Personally, I'm quite glad that the compiler is able to check that the values are all non-equal etc. If I want a series of options to be considered in order, I can write that. Having a general pattern-matching syntax *as well* would be nice, but I think that could be made rather more powerful than switch/case. – Jon Skeet Dec 11 '11 at 21:56
  • 2
    Right. A while ago I was in love with VB because it's a forgiving language. But since I got used to C# and its strictness, I realize that's it feels much better when all the edges are closed. I do use VB.NET for XML and for some certain things. C# can't beat VB.NET XML literals. That feature IS VB.NET hotness I love it very much! Thanks for you input Jon rock it on! – Shimmy Weitzhandler Dec 11 '11 at 23:37
10

This is because the value cannot be determined at compile time (as it is coming out of a configuration setting). You need to supply values that are known at the time the code is compiled (constants).

Jim Petkus
  • 4,500
  • 25
  • 19
6

What it's basically saying is that it needs to ensure that the value for each case will not change at runtime. Hard-coding your string in-line like you did on the second case will ensure that the value won't change at run time (as would declaring a 'const' variable and assigning it the hard-coded string as a value).

The first case is making a call into a property of a class, the value of which isn't known to the compiler at compile time.

If you have some 'configuration' values that are pretty much doing to be constant within your application, you might consider creating a class where you can hard-code these values are const variables and use those in your switch statements. Otherwise, you're likely going to be stuck with having to use if/else if statements.

Jesse Taber
  • 2,376
  • 3
  • 23
  • 33