首先感謝各位版上高手賜教 ^__^

※ 引述《tropical72 (藍影)》之銘言：
: 回個文整理一下。
: 先說結論，C 語言用到 big/little 的時機很少，除了幾道面試題、網路程式之外，
: 沒見過。 bitwise operator 不需考慮 big/little。
: ※ 引述《applecool (noOneKnows)》之銘言：
: : 大家好，我來求教
: : 關於 endian 我原本的理解是，在 C++ 拿到的整數值就是一般課本介紹的方式。
: : 比如說 short int a = 4 就一定會是 0x04 而不會是 0x40。

        對不起我這邊真的寫錯了，沒注意到。

        好像寫成 unsigned char 才是 nibble 的 endian？

: 推 Bencrie:0x00 0x04 跟 0x04 0x00，不是0x40  0x04                  02/02 00:15
: 這裡用 short int 將使得討論空間變大。
: : 只有在記憶體中才可能依照機器而有不同的實際排列，maybe 0x04, 0x40, 0x20, 0x02...
: 你確定知道 big/little 在記憶體長怎樣嗎？

其實我原本是想指 bit、nibble、byte 的 endian。

因為我原本理解是完全照機器自己的實作方式，

真的不知道會實作成什麼樣子，理論上大概有 N 階乘的可能吧。

(不過我想常見的應該就那幾種。)

那高階語言應該不用管才對吧？

可是如果不重新編譯，直接拿 A 機器出來的執行檔去 B 機器 run，似乎不一定對？

(Java 感覺沒這問題？？？)

其實我真的不知道在記憶體裡面到底長怎樣，我以前曾經猜想

用 union bit array 去做，和強迫轉指標型態讓編譯器去重新計算 step，

如宣告成 3 個 char 就可以 +1 跳三個 byte

我也不知道這樣正不正確？

(沒有跨機器，也沒有去驗證奇數 byte 的 step 是否可能會異常。)

: : 所以如果我今天要取出 a 除以 16 的餘數。
: : 假設 a > 0 就是 a & 0x0F，而不是 a & 0xF0 或其他的
: 你可以想一下，即使是 0x0F 也符合 big/little 原則，
: 因此在做 bitwise operator 時是不需考慮 big/little 問題。

因為我原本想 0x0F 是常數，也許根本沒有存在記憶體裡面。

: : 因為似乎網路上有些文章也是這樣寫，但上次看到另一篇文章說這樣可能會錯？
: : 他說程式中拿到的值並沒有規定一定最左邊 MSB、最右邊LSB由小到大。
: 由於這段蠻引人暇想，所以請附原文。

小弟在發文的時候找了好久，實在找不到當初的那一篇，

印象中好像是一個中文的論壇還是某人的部落格，但意思確實是那樣，

聽版友的意思是該文有誤？

: : 所以在寫 bit operation 要考慮 endian，
: : 因為從沒遇過這種情形，也查不到，
: : 所以上來求教是否高階程式語言看到的值真的不一定是如此？
: : 抱歉程式沒學很好，請求賜教，謝謝！
: 一般而言目前我還沒遇過對數值進行 bitwise operation 時會考慮到 big/little，

那請問 scanf / fscanf 要考慮嗎？我做實驗好像是不用管？

: 目前看到的大多是版友們從面試題目裡拉出來討論時才知道原來有人會考這個。
: 拿一個基礎題型：怎麼知道目前系統是 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，或計算機組織與結構 <<算盤本>>

自己基礎沒打好覺得很慚愧，謝謝各位指教
※ 編輯: applecool       來自: 123.110.136.14       (02/03 03:05)
→ azureblaze:機器架構不同你一定得recompile
→ azureblaze:所以endian純粹是已經寫下來的資料的問題
→ azureblaze:像是檔案、網路傳送、以byte為單位直接存取記憶體
推 LPH66:要考慮到 bit 順序的我只有在壓縮相關的程式裡看過而已
→ LPH66:那裡為了把基本單位是 bit 的東西打包成 byte 才要指定順序
→ LPH66:其實就和 short 放進以 byte 為單位的記憶體也要看順序一樣
→ hilorrk:需要重新編譯可不只是endian的問題