Char類型（32位和64位）

Question

這是以下問題：

如果我在32位計算機上進行開發，並且希望將我的代碼移植到64位計算機上，那么這就是senario。

我的函數內部使用了很多std字符串。 現在，如果我想提供API，我可以要求他們發送char * ，然后在內部使用嗎？ 還是要求他們給我發送__int64並將其轉換為字符串？

在我的API中使用char *另一個原因是，至少在unix的一種實現類型（工具的不同版本）中，它通過argv從stdin拾取數據，而argv是char * 。

在Windows版本中，我不確定該怎么辦。 我可以要求__int64 ，然后將其轉換為字符串...並使其以這種方式工作，或者也可以使用char * ？

Answer 1

如果要提供C ++實現，則您的公共接口應該只使用std::string 。

但是，如果出於兼容性的原因（聽起來可能是您所需要的）需要提供C風格的接口，那么使用char*正是這樣做的方法。 在您的32位庫中，它將是32位指針，在庫的64位版本中，它將是64位。 然后，這將符合客戶用戶對API的期望。 但是，您應該盡早在庫中絕對將其轉換為std::string 。

Answer 2

您最好盡早轉換為字符串，這是C ++的推薦/標准，它將有助於消除所有char *問題。

您可以遵循幾種方案來編寫可移植的代碼，請參閱以下問題：
您曾經提出過的最有趣的用戶請求是什么？
如何在沒有編譯器警告的情況下進行可移植的64位算術運算

您將在實現不同體系結構之間的二進制可移植性時遇到問題，C ++提供了源代碼級可移植性。

Answer 3

在32位和64位系統上， char始終為一個字節。 但是，使用std庫並不是最糟糕的選擇。 ;） std應該處理不同的平台，因為它對於“最”部分是獨立於平台的。

Answer 4

如果您無法在體系結構中表示數字，則向char*轉換/從char*轉換實際上並沒有幫助。

如果要將64位整數從其十進制（或十六進制）文本表示形式轉換為值，則仍需要64位存儲它。

Answer 5

您似乎有些困惑。 如果您正在編寫的代碼僅在目標計算機中使用，則重新編譯將解決大多數問題。 只是不依賴於特定的內存布局就可以了。 使用字符串（與wstrings相對）可能意味着字符編碼為UTF-8（如果不是，請重新考慮），因此在平台之間使用有限形式的數據展示（例如文件）也是可以的。

在這種情況下，您的接口決定是在(const) std::string(&)和(const) char*, integer_type （請不要依賴空終止符）。 決定因素是您是否預期需要支持其他編譯器或編程語言。

現在，如果您打算使該接口可從其他計算機調用（即網絡接口），則您的工作將會更加艱巨。 在這種情況下，請明確指定所有內容的大小。