Thread: Switch case variable scope

Ran into something today that does not make sense:

This compiles:

Code:

int x = 5;

switch(x)
{
    case 0:
    {
         int value = 5;
    }
    break;
    
    case 1:
    {
         int value = 6;
    }
    break;
}

This does not:

Code:

int x = 5;

switch(x)
{
    case 0:
    {
         int value = 5;
    }
    break;
    
    case 1:
         int value = 6;
         break;
}

Ok so it doesn't like int value = 6 b/c of int value = 5 for case 0. However since the value in case 0 is declared within the brackets one would think it has case scope.

So I tried this:

Code:

int x = 5;

switch(x)
{
    case 0:
    {
        int value = 5;
    }
    break;

    case 1:
         value = 6;
         break;
}

Now it doesn't like it b/c value has not been declared in case 1:. These two conditions cannot possibly be both true at the same time. You cannot disallow the declaration of value in case 1 b/c it interferes with value in case 0 and at the same time disallow me to use value from case 0 b/c it is not in scope. If it was not in scope then theoretically I should be able to declare value in case 1.

Both MSVS 2012 and 2013 exhibit the same behavior. I checked the standard and it is unclear on the matter.

Any explanations?

O_o

C or C++?

*shrug*

Several possibilities depending on language, how "Visual C++" parses expressions, and which example.

The most likely explanation:

1): You can't jump over declarations having assignments in C++.* (The scope from the `case' is different than the scope of the `switch'.)
2): You can't implicitly declare variables in C++.

Soma

*): From what I recall, some stuff may be related to "dumb" variables, but "Visual C++" may not honor that in any event.

Uh...its for C#.

O_o

Sorry, I had just been reading "techboard".

*shrug*

[Edit]
Actually, I've never looked at C#5 so this behavior may have changed.

Of course, I only really ever tried C#2 for any real project so it also may have changed and I just didn't notice.
[/Edit]

I imagine this is born of C# having broken "shadowing" rules.

In other words, you probably got it wrong in the second example; the compiler probably see `int value = 6;' as local to the `switch' so `int value = 5' "shadows" the `6' version.

Yeah, the "shadowing" works differently in `switch' than it does in other cases.

[Edit]

Code:

int x = 5;
 
switch(x)
{
    case 0:
    {
         int value = 5;
    }
    break;
     
    case 1:
    {
         int value = 6;
    }
    break;
}

--or--

Code:

int x = 5;
 
switch(x)
{
    case 0:
         int value = 5;
    break;
     
    case 1:
         value = 6;
    break;
}

[/Edit]

Soma

It's because of a how C# scope and switch statements work:

1. Unless you use brackets, the scope of a variable in a switch statement is the entire body of the switch statement.

2. In general, you cannot have the same variable used in a nested scope and its parent's scope (with a few exceptions). This is essentially what your second example is - the variable being defined both in the switch scope and the case scope.

The following is also not allowed, and it's basically what you're doing:

Code:

void foo()
{
      {
            int i = 2;
      }
      int i = 1;
}

Originally Posted by phantomotap

I imagine this is born of C# having broken "shadowing" rules.

I wouldn't really say "broken". C# is much stricter about the circumstances in which you can shadow variables as a deliberate design decision.

Essentially, you can shadow a class member within a class method, and you can shadow an outer class member within an inner class member, but most other cases of variable shadowing are forbidden. Even in cases where you CAN shadow, there are restrictions that you can't use the same unqualified name to refer to two entities in the same declaration space. For example, this doesn't work:

Code:

class foo
{
     private int x;
     void bar()
     {
          x = 5;  // To compile, you must use this.x = 5; instead
          // ...
          int x;
          x = 10;
     }
}

I wouldn't really say "broken". C# is much stricter about the circumstances in which you can shadow variables as a deliberate design decision.

O_o

Yeah, well, it is broken, and the thing is broken because C# isn't much stricter; C# is only inconsistent.

If C# didn't allow any "shadowing", I'd be on the same page with "much stricter", but as is, the inconsistency just makes the allowed occasions surprising to some and the disallowed occasions surprising to others.

Yeah, it is a quality of implementation issue, but I have tools here to error on "shadowing" for C, C++, Javascript, and Python. C# should have just went the sane route and disallowed it altogether.

Soma