0x0F>>2は何故答えが3になる？

質問

0x0F>>2は、僕は答えは3.75になると思うんですよ。何故小数部が切り捨てられているのですか？

回答No.6

nak777r · ベストアンサー

16進表記で 0x0F
２進表記で 0000 1111
>> 2 なので、ビットを2ビット右にシフト（ずらす）
２進表記で 0000 0011 になる、これを
16進表記で 0x03
10進表記なら 3

回答No.5

Tacosan

何をどう「思った」のか知らんけど....

「仕様を見てみよう」とは考えもしないのかなぁ.

回答No.4

kmee

<<,>>はビットシフト(ビットのパターンを前後にずらす操作)のための演算子であって、かけ算/割り算の演算子ではない、というのが1点
(結果として、かけ算/割り算になりますが)

はみ出したビットは捨てられる、というのがJavaの<<,>>演算の規則になっている、というのが1点

<<,>>の対象は整数だけ、というJavaの規則になっている、というのが1点

整数に対する演算は、基本的に整数になる、というJavaの規則になっている、というのが1点
0x0f / 4 も3.75にはなりません。
0x0f / 4.0 だと 3.75になりますが、これは暗黙の型変換が行われるから。

回答No.3

wormhole

整数と整数の演算なので結果は整数にしかなりません。
(15 / 4 の答えは3.75ではなく3です)
またビットシフト演算子は左辺、右辺には整数しか扱えません。

回答No.2

bajutsu

小数点分の領域が確保されていないから。

内部でどうメモリ確保されているかを考えてみてください。

回答No.1

hitomura

ビットシフト演算ではシフトの結果「はみ出した」部分は消滅するためです。

型だけに注目して書くと、ビットシフト演算は整数と整数から整数を求める演算です。

0x0F を2進数で表すと
　0000 1111
となります。これを2ビットシフトさせると、
　??00 0011 11
となりますが、>> の場合はシフトして「足りない」部分（上記の?の箇所）はその値の符号が入ります。
一方シフトして「はみ出した」部分（上記の11だけの箇所）は整数型では表すことのできない部分なので無くなったものとするしかありません。
したがって、0x0F>>2の結果は
　0000 0011
となり、10進数で3となります。

この演算方法は機械語からC言語経由で受け継がれたものなので、そういうものだと覚えるしかないです。
8086 CPUでいうと、参考URLの「ビットシフト演算」にあるもののうちで、以下が Java の各演算子に対応します（他の CPU でも同様の演算を持っています。演算の名前ではなく演算の動作に注目してください……Java には無い CF と書かれた部分については無視して）。
　SAL,SHL（どっちでも同じ動作） → <<
　SHR → >>>
　SAR → >>

参考URL：

http://software.aufheben.info/kouza/beginner/kouza_asm.html