推 Bencrie:0x00 0x04 跟 0x04 0x00，不是0x40 0x0402/02 00:15
這裡用 short int 將使得討論空間變大。
: 只有在記憶體中才可能依照機器而有不同的實際排列，maybe 0x04, 0x40, 0x20, 0x02...
你確定知道 big/little 在記憶體長怎樣嗎？
: 所以如果我今天要取出 a 除以 16 的餘數。
: 假設 a > 0 就是 a & 0x0F，而不是 a & 0xF0 或其他的
你可以想一下，即使是 0x0F 也符合 big/little 原則，
因此在做 bitwise operator 時是不需考慮 big/little 問題。
: 因為似乎網路上有些文章也是這樣寫，但上次看到另一篇文章說這樣可能會錯？
: 他說程式中拿到的值並沒有規定一定最左邊 MSB、最右邊LSB由小到大。
由於這段蠻引人暇想，所以請附原文。
: 所以在寫 bit operation 要考慮 endian，
: 因為從沒遇過這種情形，也查不到，
: 所以上來求教是否高階程式語言看到的值真的不一定是如此？
: 抱歉程式沒學很好，請求賜教，謝謝！
一般而言目前我還沒遇過對數值進行 bitwise operation 時會考慮到 big/little，
目前看到的大多是版友們從面試題目裡拉出來討論時才知道原來有人會考這個。
拿一個基礎題型：怎麼知道目前系統是 big/little ? #1CU0HUdf
我比較好奇的是，除了網路程式外，有地方需要知道這個嗎？
<< 若是用 winsock2, 其實 api 也都處理好大小邊問題 >>
bitwise 推文補充
→ diabloevagto:用bitwise也不用考慮嗎？02/02 00:38
→ tropical72:bitwise只需考慮長度是否一樣 及 signed bit.02/02 00:40
長度一樣 指的是下面這種情形
unsigned short x=0x12345678;
printf("%hx\n", x);
將 unsigned int 0x12345678，assigned to unsigned short x,
最後只會存 2 bytes 下來，且不論 big/little，結果一定是 0x5678，
意思是前面的 0x1234 是白寫的。
signed bit 本身問題較大，這裡只點一下。
所有問題都集中在對「有號數」進行 bitwise 操作，
有些操作並不能預期它對 signed bit 是如何處理，
最明顯、最有爭議的是這段 int x=-1, x<<=1;
答案「不一定」會是 -2 ， 實際上的作法是 取決於編譯器 << 不是取決於 CPU >>，
<< 侯 sir, C++ Primer 4e, p155 >>
只是目前大多編譯器實作出來是 -2 而已，而且有不少文章都基於此種假設進行發表，
另也有些人，甚至某些團隊，在做左右移時會針對 signed 特別再處理。
至於 -5 & 0x0f 和 -5 % 16 ，這兩行是否相等，答案是「不一定」，
因這二個行為都屬未定義行為，前者 depends on compiler，
後者 depends on machine，以我的環境和 compiler 結果是 11 -5。
結論是，如果確定是無號數時，就不用考慮 大小邊 ，放心用 bitwise 吧。
其他的詳看 C++ Primer，或計算機組織與結構 <<算盤本>>
--
世界上有種，
將 不可能 轉換為 無限可能 的強大力量，
我稱它為 - 信念。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.195.165.40
→ hilorrk:寫emulator(binary translator) 如果source ISA和target 02/02 19:18
→ hilorrk:的endian不一樣也需要處理...雖然我自己沒寫過啦XD 02/02 19:19
推 Slither:0x0f 是 15? 02/05 23:27