這道題很古老了，可別將它和大端轉小端混淆了，所謂大端和小端指的是位元組序，而這裡反轉乙個位元組說的是位序，演算法更是不勝列舉，說實話都能達到目的，剩餘的就是看看誰的效率更高了，基本上這是乙個最難的問題，高手不是能寫出最美麗的程式而是能寫出既美麗同時效率又是最高的程式，如果乙個人寫的程式很美麗，很直觀，只能說明該程式設計師對語言掌握的很好，但是語言畢竟只是工具，真正做事的是計算機，只有對計算機很了解，才能寫出效率最高的程式，正如文學家的文筆很多不如花季少女，但是花季少女永遠也超越不了時代。
不管什麼樣的程式，落實到底層的cpu都是那幾樣，盡量不要使用跳轉，因為會清空流水線，相比之下，跳轉的危害在x86機器上intel比amd更甚，因為後者的流水線更淺；充分利用超標量cpu的超標量特性，也就是盡量使相鄰指令不要關聯，這樣可以亂序執行，亂序執行就是將指令發射到不同的流水線序列；徹底理解cpu的ht特性，ht不一定會更好，因為它們畢竟是要共享一套算術單元，有時切換的開銷會抵消對空閒週期的彌補，總的看來，cpu型別的程式應該避免使用ht，對映到程序/執行緒模型，並不是執行緒越多越好，當執行緒太少，不能利用多cpu特性，並且可能會使cpu閒置，但是太多的話又會引入切換/儲存上下文開銷，因此執行緒的數量和cpu數量相等或者比cpu數量大1個或者2個最好，因為強制和cpu數量相等會加大作業系統的執行開銷，並且萬一執行緒陷入io沒有替補，因此windows的io完成埠就設計的特別好，windows核心會限制完成埠上的活躍執行緒和建立時傳入的引數一致，但是我並不贊成這種策略在核心實現，因此機制和策略嚴格分離的unix就沒有這麼做，你完全可以在使用者空間通過cpu繫結和執行緒數量限制來調優；要盡可能的利用cpu的l1/l2 cache，理想情況就是，靜態資料在cache中，該執行緒永不換出，cache永不重新整理，但是這僅僅是一種理想，因此就要在理想和現實之間折中，將靜態資料減少，既然不能將cache歸為己有，那麼也沒有必要為止付出太多空間開銷。
在上一段的指導下，高效的演算法應該是很少的跳轉，也就是很少的判斷，不多不少的靜態資料，該演算法是cpu型別的，ht應關閉，如此的條件用彙編最好了，但是還要和另乙個條件折中，這就是程式的美觀性，於是還是用c吧：
unsigned char func( unsigned char c)
static unsigned char sta[16] = //不多不少的靜態資料
0x00,0x08,0x04,0x0c,0x02,0x0a,0x06,0x0e,0x01,0x09,0x05,0x0d,0x03,0x0b,0x07,0x0f
unsigned char d = 0; //沒有判斷
d |= (sta[c&0xf])
d |= sta[c>>4];
return d;
小聲說一句，此題的解法甚多，比如可以定義乙個大表，比如可以用二分法，或者按照管道的思想，一端進一端出，其實就是堆疊，將乙個數按照一位一位的進入乙個堆疊，然後再彈出，如果不是按位倒序，linux核心中有足夠的演算法供你參考，如果你在筆試時寫上了linux核心的演算法，那麼考官最起碼會覺得你說的讀過核心並不假，但是可悲的是考官他自己不一定讀過核心。要知道很多30歲以上的軟體工程師都不一定能寫出什麼高效的演算法，我們公司就有一批這樣的可悲人群，乃不知有暫存器，無論堆疊！
經典 反轉乙個位元組
這道題很古老了，可別將它和大端轉小端混淆了，所謂大端和小端指的是位元組序，而這裡反轉乙個位元組說的是位序，演算法更是不勝列舉，說實話都能達到目的，剩餘的就是看看誰的效率更高了，基本上這是乙個最難的問題，高手不是能寫出最美麗的程式而是能寫出既美麗同時效率又是最高的程式，如果乙個人寫的程式很美麗，很直觀...
乙個字等於多少位元組？
在這個特定計算機中，字是其用來一次性處理事務的乙個固定長度的位 bit 組。現代計算機的字長通常為16 32 64位。結合以上兩句，我覺得乙個字佔多少位元組並不是那麼絕對的，要看你是哪個處理器 處理器的位數決定了能夠處理一條指令的長度 以前我看書上也是說乙個字就是兩個位元組，這是因為我們之前接觸的8...
位元組筆試 乙個字串是否可以構成乙個圓環
include include include include include include include include include include include include include using namespace std bool f string s int n s.si...