/演算子よりも>>演算子を使用する利点は何ですか?それは私が維持しているコードで広く使われていました。たとえば、
int width = previousWidth >> 2;
4 に答える
値を特定のビット数だけシフトしたい場合、理解するのはかなり簡単です。例えば:
byte[] bits = new byte[4];
bits[0] = (byte) (value >> 24);
bits[1] = (byte) (value >> 16);
bits[2] = (byte) (value >> 8);
bits[3] = (byte) (value >> 0);
それは明らかに異なるビット数でシフトしています。それを割り算で表現したいですか?
もちろん、本当に除算が必要な場合は、読みやすくするために除算演算子を使用する必要があります。パフォーマンスのためにビットシフトを使用する人もいますが、これまでと同様に、ほとんどのコードではマイクロ最適化よりも可読性の方が重要です。したがって、あなたの場合、実際に必要なのは4で割るwidth
ことpreviousWidth
である場合、コードは*絶対にそれを反映する必要があります:
int width = previousWidth / 4;
パフォーマンスの違いが重要であることを証明した後でのみ、ビットシフトを使用します。
他の人がすでに言ったように、最適化よりも読みやすいオプションを常に優先することをお勧めします
- 間違いなくその最適化が必要です
- によって機能することを知っている
- コンパイラを知る
- JVMを知る
- パフォーマンス測定の実施
- それらの測定値の統計的評価の検討 (極値、分散、最初の測定値と後の測定値、...)
これらは異なる操作です:
>> 2
ビット パターンを 2 ビット右にシフトします (基本的に、整数を 2^2 = 4 で除算します)。/ 2
数を 2 で除算します (これは として実装できます>> 1
)。
を使用>> 1
して他の数値型を 2 で除算すると、予期しない結果になる可能性があることに注意してください。
「2 で割る」という意味であれば、「/ 2」と入力します。あなたのコードを読んでいる人 (後であなたを含む) は、意味を曖昧にしていないことに感謝するでしょう。
ほとんどの場合、何もありません。除算をビットシフトに変えるのはJVMの最適化です。
ビットマスクに対して行われている場合は問題ありませんが、上記の場合のように、数学演算の書き方がぎこちないように見える場合は、メンテナンスの一部として変更することを検討してください (または、単に悪い考えとして受け入れてそのままにしておきます)。それだけです)。