要考慮編寫可移植到32位和64位體系結構的代碼的要點

在編寫應該可在32位和64位計算機上移植的代碼時應該記住哪些要點？要考慮編寫可移植到32位和64位體系結構的代碼的要點

思考更多關於這一點，我覺得如果你能interms面臨問題，這將有助於增加你的經驗。

這個雪上加霜的是，有一次我遇到一個問題，由於缺少原型爲其返回返回一個指針的函數。當我將它移植到一臺64位機器上時，代碼崩潰了，我不知道相當一段時間的原因，後來才意識到所有丟失的原型都被假定返回int來引起問題。

任何這樣的例子都可以提供幫助。

編輯：添加到社區wiki。

2010-02-12 Jay

社區wiki？ – jamessan 2010-02-12 18:40:20

請參閱http://stackoverflow.com/questions/411798/converting-32-bit-application-into-64-bit-application-in-c – Christoph 2010-02-12 18:42:29

和http://stackoverflow.com/questions/534941/team-is -XP32-to-xp64-for-net-development-any-gotchas/535154＃535154 – lsalamon 2010-02-12 18:46:41

陷阱：

轉換指針爲整數類型是危險
數據結構的大小可以改變
當心符號擴展
不同ABI？

一些技巧&技巧我發現有幫助：

讓自己的本機大小的整數類型（從頭部或typedef你自己的），並使用它時，你有沒有變數關心大小。
使用明確的變量類型儘可能（u_int64_t，int_32_t等）

來源

2010-02-12 18:40:19

一些積分類型可以具有不同的尺寸
指針是不同長度的
結構填充
對齊

在Windows上，僅呼籲在x64約定，而不是將M在普通的x32機器上重複使用。

當你有一些32位和64位的組件時，事情會變得更加混亂。在Windows上，我最終寫了一個COM服務讓他們說話。

來源

2010-02-12 18:41:28 dirkgently

將指針推入堆棧佔用兩倍的空間。儘管堆棧大小在操作系統版本之間可能不會改變，導致在32位編譯運行良好的代碼在64位編譯和運行時發生神祕故障。不要問我怎麼知道這一點。

來源

2010-02-12 18:43:00

我從來沒有聽說過這個。這真的會影響嗎？ – Jay 2010-02-12 18:51:05

呃...是啊... – 2010-02-12 19:05:41

只有當編譯器不能/不將指針存儲在寄存器中時，纔是如此。 – philant 2010-04-30 15:11:41

編寫自動化測試並在兩個平臺上定期運行測試。

來源

2010-02-12 18:43:41

sizeof（int）might！= sizeof（void *）

alignment。對齊需求可能會發生變化。這可以暴露錯誤的地方，如果接受者期待指針，則不應該將0傳遞給可變參數。如果接收者期待指針，則可以將0忽略到應該已經對齊的對象中，但僅在32位（或者在不關心的處理器上）這在C++中很痛苦，在這種情況下，精明的開發人員知道0是一個有效的空指針。 C開發人員通常會使用NULL，因此您可能確定

來源

2010-02-12 18:47:59 pm100

+1現在我想知道如果這種行爲是合規的。該標準說空值計算爲0.它不應該被默認提升爲（void *）嗎？不是你不應該使用NULL，而是閱讀標準，頭文件編寫者可以將NULL定義爲0. http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf請參閱point 3對6.3.2.3。這聽起來像GCC是錯誤的，或者一旦這是目前的標準將是錯誤的。 – jbcreix 2010-02-12 23:07:14

在我的情況下，gcc將NULL轉換爲nullptr。所以它工作。我同意，如果NULL被定義爲0，那麼它不會修復我的錯誤，在這種情況下，我將不得不明確地說（void *）0 – pm100 2010-02-13 00:43:05

要考慮編寫可移植到32位和64位體系結構的代碼的要點

回答

相關問題