一方が他方よりも非効率的かどうか疑問に思っていました (以下の 2 つのコード)。
if ( abc & myType == myType )
{
if (myValue)
{
// do something
}
}
また
if ( (abc & myType) && myValue )
{
// do something
}
一方が他方よりも非効率的かどうか疑問に思っていました (以下の 2 つのコード)。
if ( abc & myType == myType )
{
if (myValue)
{
// do something
}
}
また
if ( (abc & myType) && myValue )
{
// do something
}
それらは同等ではありません。「修正された」2番目のものは次のようになります
if ( (abc & myType == myType) && myValue )
{
// do something
}
この場合、まともなコンパイラは両方に対して同じコードを出力します。
また、この種のマイクロ最適化を行うことはほとんど賢明ではありません。重要ではないコード パスであっても、せいぜい 1 つまたは 2 つのアセンブリ命令の違いに時間を浪費することになります。ここでは、パフォーマンスに実際の違いはありませんが、実際に行うべき最適化は、コードを明確にすることです。
真の最適化とは、これらの微小な差異 (おそらくコンパイラーによってすでに取り除かれているもの) を気にせず、代わりにコードをプロファイリングして真のボトルネックを見つけることです。
他の何人かは、この理由から 2 つが同等ではないことを指摘しています。
if (abc & myType == myType )
{
if (myValue) {}
}
// OR
if ( (abc & myType) && myValue ) // missing myType == myType
{}
ただし、2 つが同等ではない 2 つ目の理由があります。==
演算子は演算子よりも優先され&
ます (このリンクを参照してください)。したがって、最初の式は次のように評価されます。
if (abc & myType == myType) // Evaluates to (abc & true)
{
if (myValue) {}
}
あなたはおそらくこれを意図していました:
if ((abc & myType) == myType) // Now the bitwise and happens before
// the comparison is made
{
if (myValue) {}
}
この種のバグを正確に回避するために、人間の観点からあいまいさの可能性がある場合は常に括弧を使用して優先順位を強制します (コンパイラーはあいまいさを決して見つけませんが)。実際の優先順位は次のとおりです。これには、コードが読みやすくなるという追加の利点があります。