ビットシフト演算の罠

ビットシフト演算は2のn乗の掛け算/割り算の代わりになります。 例えば a という数を4で割りたい場合は
a >> 2
とすることでできます。割り算をするよりも非常に高速にできます。 なのでADコンバータの読み取り値を平均化するときなどは10個分や100個分で平均するのではなく、 8個分や256個分で平均化し、ビットシフト演算で割り算をした方が良いです。

ところがここにも罠が潜んでいます。以下のコードを見てください。
int a, b;
a = 24;
b = a >> 2 + 1;
b には何が入るでしょう？　24を4で割って1を足しているから7になりそうな気がします。 誰だってそう思います。僕もそう思います。 しかし現実は無情。 b には3が入ります。

実はこれは演算子の優先順位が原因です。 ビットシフトは掛け算、割り算の代わりなのだから、足し算よりも優先順位が高いと普通は考えます。 しかし実際はビットシフトは足し算よりも優先順位が低いのです。 つまり足し算が先に計算されて a を3つビットシフトさせることになります。 つまり24を8で割ることになり、答えは3になります。 これはPICの罠というよりかはC言語そのものの仕様による罠です。 なんでこんな仕様になっているのか謎です。 ビットシフト演算と他の演算を使う時は括弧をつけるようにしましょう。
int a, b;
a = 24;
b = (a >> 2) + 1;