まあ、与えられた数が偶数かどうかを判断する低レベルの方法は少なくとも 2 つあります。
1. if (num%2 == 0) { /* even */ }
2. if ((num&1) == 0) { /* even */ }
私は 2 番目のオプションの方がはるかにエレガントで意味があると考えており、通常はこれを使用しています。しかし、これは単に好みの問題ではありません。実際のパフォーマンスは異なる場合があります。通常、ビット単位の演算 (ここでは論理積など) は、mod (または div) 演算よりもはるかに効率的です。もちろん、一部のコンパイラはいずれにしても最適化できると主張するかもしれませんし、私も同意しますが、最適化できないコンパイラもあります。
もう 1 つのポイントは、経験の浅いプログラマーにとっては 2 番目のステートメントを理解するのが少し難しいかもしれないということです。これについては、これらのプログラマーがこの種のステートメントを理解するのにそれほどの時間を割くことが、おそらくすべての人にとって有益であるだろうと答えます。
どう思いますか？
num与えられた 2 つのスニペットは、unsigned int または 2 の補数表現を持つ負の数である場合にのみ正しいです。 - いくつかのコメントが正しく述べているとおりです。
ベストアンサー1
私はまず読みやすさを重視してコードを書くので、 を選びますnum % 2 == 0。これは よりもはるかに明確ですnum & 1 == 0。最適化についてはコンパイラに任せ、プロファイリングでこれがボトルネックであることが示された場合にのみ調整します。それ以外のことは時期尚早です。
私は2番目の選択肢の方がはるかにエレガントで意味があると思う
私はこれに強く反対します。数が偶数なのは、2 を法とする合同性が 0 であるからであり、バイナリ表現が特定のビットで終わるからではありません。バイナリ表現は実装の詳細です。実装の詳細に頼ることは、一般的にコードの臭いです。他の人が指摘しているように、1 の補数表現を使用するマシンでは LSB のテストは失敗します。
もう 1 つのポイントは、経験の浅いプログラマーにとっては 2 番目のステートメントを理解するのが少し難しいかもしれないということです。これについては、これらのプログラマーがこの種のステートメントを理解するのにそれほどの時間を割くことが、おそらくすべての人にとって有益であるだろうと答えます。
私は同意しません。私たちは皆、意図がより明確になるようにコーディングする必要があります。偶数かどうかをテストする場合は、コードでそれを表現する必要があります (コメントは不要です)。繰り返しますが、2 を法とする合同性をテストする方が、LSB をチェックするよりもコードの意図がより明確に表現されます。
さらに重要なのは、詳細はisEvenメソッド内に隠しておく必要があるということです。したがって、の定義ではif(isEven(someNumber)) { // details }と を 1 回だけ見る必要があります。num % 2 == 0isEven