0
switch (indexPath.section) {  
  case 0: //products used  
    NSString * chemical = [selectedChemicals objectAtIndex:indexPath.row];  
    cell.textLabel.text = chemical;  
    break;  
  case 1: //areas sprayed  
    return [selectedAreas count];  
    break;  
  case 2://target pests  
    return [selectedPests count];  
    break;  
  case 3://notes  
    return 1;  
    break;  
}

gives me:   "/Users/grady/programming/ObjectivelyBetter/bioguard/Classes/JobWizardViewController.m:147: error: 'chemical' undeclared (first use in this function)"

putting a blank semi-colon at the beginning of the case fixes it.

switch (indexPath.section) {  
  case 0: //products used  
    ;  
    NSString * chemical = [selectedChemicals objectAtIndex:indexPath.row];  
    cell.textLabel.text = chemical;  
    break;  
  case 1: //areas sprayed  
    return [selectedAreas count];  
    break;  
  case 2://target pests  
    return [selectedPests count];  
    break;  
  case 3://notes  
    return 1;  
    break;  
} 
Tommy
  • 1,277
  • 1
  • 11
  • 22
Grady Player
  • 14,399
  • 2
  • 48
  • 76

1 Answers1

2

When you declare variables within a case statement, it's a good practice (and required to avoid these kinds of errors) to enclose the statements inside curly braces, e.g.

case 0:
    {
        int i = 0;
        ....
        break;
    }

Not sure why a semicolon along would have "solved" the issue. That's kind of odd... the curly braces are what you need.

In your particular case you could also just eliminate the local variable declaration and set the cell textLabel like so:

  cell.textLabel.text = [selectedChemicals objectAtIndex:indexPath.row];
Mark Granoff
  • 16,878
  • 2
  • 59
  • 61
  • you're right, as for the weirdness... I think I have it figured out sort of, it has to do with switch expansion. the semicolon is the whole expression for the first case, then it just falls through to the second expression... third expression, until it reaches break. seems like a bug in GCC to not perform consistent constraint checking. – Grady Player Apr 22 '11 at 20:11
  • I saw this same problem years ago using plain old C and C++ on Solaris. It's not a new thing, but more surprisingly, it's still a "problem." Live and learn I guess. Funny how "best practices" are often patterns that work around things that are anything but "best". :-) – Mark Granoff Apr 22 '11 at 20:13