字符串类型为32位与64位

Question

以下是以下问题：

如果我在32位计算机上进行开发并希望将代码移植到64位计算机上，那么这就是senario。

我的函数在内部使用了很多std个字符串。现在，如果我想提供API，我可以让他们发送char *然后我可以在内部使用吗？或者让他们发给我一个我转换成字符串的__int64？

在我的API中使用char *的另一个原因是，至少在一种类型的unix实现（该工具的不同版本）中，它通过stdin从argv获取数据这是一个char *。

在Windows版本中，我不知道该怎么做。我可以要求__int64，然后将其转换为字符串...并使其以这种方式工作或仅使用char *？

Answer 1

如果您要提供C ++实现，那么您的公共接口应该只使用std::string。

如果出于兼容性原因（听起来你可能有这种情况），你需要提供一个C风格的界面，那么使用char*正是这样做的方法。在32位库中，它将是一个32位指针，在64位版本的库中，它将是64位。这将符合客户用户对API的期望。但是，您应该尽可能早地在图书馆内转换为std::string。

Answer 2

您最好尽早转换为字符串，它是C ++的推荐/标准，并将帮助您解决所有的char *问题。

您可以按照一些方案编写可移植代码，请参阅以下问题：
What's the funniest user request you've ever had?
How to do portable 64 bit arithmetic, without compiler warnings

在不同架构之间实现二进制可移植性会遇到问题，C ++提供源级可移植性。

Answer 3

在<32>和64位系统上，

char总是一个字节大小。但是，使用std库并不是最糟糕的选择。 ;）std应该处理不同的平台，因为它对于“最”部分是独立于平台的......

Answer 4

如果您无法代表架构上的数字，那么转换为char*或从{{1}}转换并没有多大帮助。

如果要将64位整数从其十进制（或十六进制）文本表示转换为值，则仍需要64位来存储它。

Answer 5

你好像有点困惑。如果您编写的代码仅在目标计算机中使用，则重新编译将解决大多数问题。只是不要依赖特定的内存布局，你没事。使用字符串（而不是wstrings）可能意味着字符编码是UTF-8（如果没有，重新考虑），因此平台之间限制形式的数据扩展（例如文件）也很好。

在这种情况下，您的接口决定是在(const) std::string(&)和(const) char*, integer_type之间进行选择（请不要依赖于null终止符）。决定因素是您是否需要支持其他编译器或编程语言。

现在，如果您打算使接口可以从其他计算机（即网络接口）调用，那么您将面临更艰难的工作。在这种情况下，明确指定所有内容的大小。