总是在 C 中转换变量是一种好习惯吗？答案

【问题标题】：Is it good practice to ALWAYS cast variables in C?总是在 C 中转换变量是一种好习惯吗？
【发布时间】：2011-11-21 18:34:16
【问题描述】：

我正在编写一些 C 代码并使用 Windows API。我想知道强制转换显然相同但名称不同的类型是否是一种好习惯？例如，将TCHAR * 传递给strcmp() 时，它需要const char *。我应该这样做，假设我想编写严格且在各方面都正确的 C，strcmp((const char *)my_tchar_string, "foo")？

【问题讨论】：

标签： c winapi coding-style casting

【解决方案1】：

不要。但也不要使用strcmp()，而应使用_tcscmp()（甚至是安全的替代方案）。

_tcs* 表示一整套 C 运行时（字符串）函数，它们的行为是否正确取决于预处理器如何翻译 TCHAR。

关于安全的替代方案，查找带有尾随 _s 的函数，否则将其命名为 C 运行时中的经典字符串函数。还有一组函数返回HRESULT，但它与 C 运行时不兼容。

【讨论】：

【解决方案2】：

不，将其丢弃并不安全，因为 TCHAR 并不总是等于 char。您应该选择一个与TCHAR 一起使用的函数，而不是强制转换。见http://msdn.microsoft.com/en-us/library/e0z9k731(v=vs.71).aspx

【讨论】：

【解决方案3】：

铸造通常是个坏主意。在不需要时施放是一种糟糕的做法。

想想如果你改变你要转换的变量的类型会发生什么？假设在未来某个日期您将my_tchar_string 更改为wchar_t* 而不是char*。您的代码仍然可以编译，但行为不正确。

编写 C 代码时，您的主要目标之一是尽量减少代码中的强制转换次数。

【讨论】：

【解决方案4】：

我的建议是完全避免TCHAR（和相关函数）。他们的真正意图是允许单个代码库为 16 位或 32 位版本的 Windows 进行本地编译——但 16 位版本的 Windows 早已不复存在，而他们正是编写这样的代码的真正原因.

如果您想要/需要支持宽字符，请执行此操作。如果您只使用窄/多字节字符就可以了，那就这样做。至少 IME，试图坐在栅栏上并同时做一些通常意味着你最终没有做好任何一个。这也意味着将所需的测试量大致增加一倍，而您提供给用户的功能甚至不会增加一倍。

【讨论】：