C++ 优化开关结构-如何避免添加if子句

我正在尝试优化一个我必须重构的代码。没有任何优化的代码将有一些switch语句。如果switch语句中发生错误，则会向调用方法返回错误，例如：

switch(var)
{ 
    case VAL1: 
    //do something... 
    break; 
    case VAL2: 
    //do something else... 
    //... 
    case VAL3: 
    if (...) // there is any case that can cause error 
    { 
         return error1;
    }
    break; 
    case VAL4: 
    if (...) // there is any case that can cause error 
    { 
         return error2;
    }
    break;
    case VAL5: 
    if (...) // there is any case that can cause error 
    { 
         return error1;
    }
    break;
    //and so on... 
    default: 
         break; 
} 

我正在重构代码，因此我没有在switch语句中返回错误，而是标记变量中存在错误：

int error_type = -1; 

switch(var)
{ 
    case VAL1: 
    //do something... 
    break; 
    case VAL2: 
    //do something else... 
    //... 
    case VAL3: 
    if (...) // there is any case that can cause error 
    { 
         error_type = error1;
    }
    break; 
    case VAL4: 
    if (...) // there is any case that can cause error 
    { 
         error_type = error2;
    }
    break;
    case VAL5: 
    if (...) // there is any case that can cause error 
    { 
         error_type = error1;
    }

    break;
    //and so on... 
    default: 
         break; 
}

if (error_type != -1) 
       return error_type; 

当没有错误时会出现问题，因为我们添加了另一个if语句，如果每秒调用该方法多次，则会导致性能问题。我希望避免每次都检查情况。有什么建议我可以改进这段代码吗？有开关重构技巧吗

---

//编辑：我知道这个例子可能看起来很愚蠢（因为那里的重构看起来不是很有用），但我正在重构的实际代码确实需要它（相信我），所以我尽量不让最终代码的性能降低

一般的经验法则是，

switch

语句可以被查找表或数组替换。这些表的一个优点是，它们可以很容易地进行更新，而性能成本很低，对查找函数（引擎）的修改也很少

以下是一些想法：

如果条件检查有模式，则将变量放入表中。让发动机执行检查

---

将函数指针放入表中以执行检查。如果函数指针为NULL，则不进行检查。

var的可能值是什么？If条件中是否有任何共性？最重要的是。您确定需要优化吗？探查器怎么说？假设var来自一组20个小整数，Thomas使用数组进行优化的建议是一个很好的建议。然而，考虑到您所展示的重构，如果您能看到性能上的任何明显变化，我会感到惊讶。如果“多次”在：每秒多次“不到10亿，那么就放松下来，尽可能编写最干净、最漂亮、最可维护的代码。你到底为什么期望这会导致性能问题？在CPU几乎肯定能够正确预测的情况下，测试局部变量的值很容易产生零影响if（…）的

开关（x）

上的code>可能是一个“负”或“零”-除非您能够以某种方式消除复杂的

if（…）

-但是，我很怀疑。确实存在使用table而不是

switch

的情况，但我不认为这是其中之一。@Matstpeterson：在这种情况下，切换到表查找可能不会提高性能，但OP还提到了一个维护问题，即始终将case添加到

switch

语句中。查找表很好地减少了维护问题。对我来说，这大致是相同的努力。。。