TM> Does it help you if I tell you that well designed code  doesn't
 TM> contain many switch statements?
 NH> How many is too many?  
 
 Well, I don't agree that the number of switch statements is any
 good indicator of code quality.  Some people like to use switch
 statements and some like to use lots of if/else ifs to do the
 same.  The only drawback I see to switches is how 'break' gets
 overloaded.
 NH> Should the switch statement be treated the same
 NH> way goto is: only under duress? (and then, don't let anybody know you
 NH> did it)?
 Not at all!
 
 But there's one "traditional use" of switch that becomes a questionable 
 practice if you want to do object oriented programming.  That's the case 
 where you have some sort of object type member embedded within the 
 object and  then perform different actions based on this type.  
 One example would be an employee setup where there's a field which 
 holds job type.  Let's further assume that you have cases where you 
 do different things based on that job classification
 double CalculateBonus (const Employee& employee) {
   switch (emp.job_code) {
     case UPPER_MANAGEMENT:
       return stock_price * media_hype;
     case TECHNICAL_STAFF:
       if (employee.IsUseless() && employee.SucksUpToBoss())
         return BIG_BUCKS;
       else
         return CHUMP_CHANGE;
     case JANITORIAL_STAFF:
         return 0;
   }
 }
 When you are choosing different actions based on type, then you
 should give strong consideration to having having different types
 of objects to represent this rather than some sort of type 
 field.  Then CalculateBonus() becomes a virtual function that
 needs no maintenance when new types of employees are created
 withing the system.
       
---
 þ Blue Wave/QWK v2.12 þ
---------------