C风格显式类型转换的搜索:a= (int)b；

Question

我有一个关于这个诊断的好处的问题。一位用户建议我们在PVS-Studio分析器中实现对C风格的所有显式类型转换的搜索。也就是说，检测这种构造的诊断：

int *x = (int *)y;
float a = float(b);
float c = (float)(d);

它的目的是将所有这些转换替换为它们更安全的版本- reinterpret_cast/static_cast/const_cast。在这样的重构过程中，可以很好地检测到代码中的一些缺陷。

当然，这不是关键错误的检测，如果我们实现这个诊断，它将在客户的特定请求一节中，并且默认情况下是禁用的。

但我甚至怀疑这种诊断的好处。所以我决定问问其他用户:还有没有人需要这个选项来搜索C风格的显式类型转换？有人愿意在他们的代码中执行这种重构吗？

Answer 1

一个常见的观点(例如expressed by Stroustrup)是C风格的转换容易隐藏错误。我假设这些视图会促使相当多的人不使用它们，所以我想反C-cast诊断应该会有一些用处。我个人并不介意这样做，因为我无论如何都会避免C风格的强制转换，但是考虑到遗留代码，我会发现这个搜索很有用。

Answer 2

我甚至会更进一步，类型转换通常是一件不好的事情，大量使用它们的代码是可疑的。这肯定是C语言的情况，其中可能发生的隐式转换的规则非常有限，并且由语言很好地定义。

由于重载，C++有点复杂，但是仍然不需要太多的显式类型转换。设计应该总是这样的，即只有一条唯一的路径将一种类型转换为另一种类型。

强制转换是不好的，因为如果被强制转换的表达式的类型发生变化，它们很容易隐藏问题。例如，在您的示例中，如果y从指针类型更改为整数类型。但在任何情况下，C++风格的转换都要好得多，无论是因为它们更容易搜索，而且输入起来真的很痛苦，人们自然会避免使用它们:)并尝试完全禁止reinterpret_cast，或者至少它应该是非常罕见的。

Answer 3

我理解C++ cast支持C cast的动机(本质上是因为C cast有时是static_cast，有时是reinterpret_cast，会有惊喜的风险)，但是...重构已经有效的东西可能会引入甚至意想不到的错误，因为你可能曲解了原始开发人员要做的事情……

除非您正在重新考虑重写逻辑(所以您不是在“逐条语句”地工作，而是在理解整体语义)，否则我不会这么做。