为什么要避免铸造？

Question

我通常会尽可能避免强制转换类型，因为我认为这是一种糟糕的编码实践并且可能会导致性能损失。

但是如果有人让我解释为什么会这样，我可能会像头灯下的鹿一样看待他们。

那么为什么/什么时候铸造不好？

它对于 java、c#、c++ 是通用的还是每个不同的运行时环境都按照自己的方式处理它？

欢迎任何语言的细节，例如为什么它在 c++ 中不好？

原文由 LoudNPossiblyWrong 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

您已经用三种语言对此进行了标记，而这三种语言的答案确实大不相同。对 C++ 的讨论或多或少也意味着对 C 类型转换的讨论，这（或多或少）给出了第四个答案。

由于它是您没有明确提及的那个，我将从 C 开始。C 转换有许多问题。一是他们可以做许多不同的事情中的任何一个。在某些情况下，强制转换只是告诉编译器（本质上）：“闭嘴，我知道我在做什么”——也就是说，它确保即使您进行可能导致问题的转换，编译器不会就这些潜在问题向您发出警告。例如， char a=(char)123456; 。定义的这个实现的确切结果（取决于 char 的大小和符号），除了在相当奇怪的情况下，可能没有用。 C 强制转换也有所不同，它们是仅在编译时发生的事情（即，您只是告诉编译器如何解释/处理某些数据）还是在运行时发生的事情（例如，从 double 到的实际转换长）。

C++ 尝试通过添加许多“新”转换运算符来至少在某种程度上解决这个问题，每个运算符都仅限于 C 转换功能的一个子集。这使得（例如）意外地进行您真正不打算的转换变得更加困难——如果您 只 打算放弃对象上的常量，您可以使用 const_cast ，并确保它 唯一 能影响的是一个对象是否是 const ， volatile ，或者不是。相反，不允许 static_cast 影响对象是 const 还是 volatile 。简而言之，您拥有大多数相同类型的功能，但它们被分类，因此一次转换通常只能进行一种转换，而单个 C 样式转换可以在一次操作中进行两到三个转换。主要的例外是，您 可以 使用 dynamic_cast 代替 static_cast 至少在某些情况下，尽管被写为 dynamic_cast ，它真的最终成为 static_cast 。例如，您可以使用 dynamic_cast 向上或向下遍历类层次结构——但是“向上”转换层次结构始终是安全的，因此可以静态完成，而“向下”转换层次结构不一定安全，所以它是动态完成的。

Java 和 C# 更相似。特别是，对于他们来说，铸造（实际上？）总是一个运行时操作。就 C++ 强制转换运算符而言，它通常最接近 dynamic_cast 就实际完成的操作而言 - 即，当您尝试将对象强制转换为某个目标类型时，编译器会插入运行时检查查看是否允许该转换，如果不允许则抛出异常。确切的细节（例如，用于“bad cast”异常的名称）各不相同，但基本原理仍然大体相似（尽管，如果没有记错的话，Java 确实会将强制转换应用于少数非对象类型，例如 int 更接近于 C 类型转换 — 但这些类型很少使用，以至于 1）我不记得了，而且 2）即使它是真的，它也无关紧要）。

从更广泛的角度来看，情况非常简单（至少在 IMO）：演员表（显然足够）意味着您正在将某些东西从一种类型转换为另一种类型。何时/如果您这样做，就会提出“为什么？”的问题。如果您真的希望某物成为特定类型，为什么不将其定义为该类型？这并不是说 没有 理由进行这种转换，但无论何时发生这种转换，它都会提示您是否可以重新设计代码以便始终使用正确的类型的问题。即使是看似无害的转换（例如，整数和浮点之间的转换）也应该比常见的更仔细地检查。尽管它们 看起来很 相似，但整数确实应该用于“计数”类型的事物，而浮点数则应该用于“测量”类型的事物。忽略这种区别会导致一些疯狂的说法，比如“美国家庭平均有 1.8 个孩子”。尽管我们都可以看到这是如何发生的，但事实是 没有一个 家庭有 1.8 个孩子。他们可能有 1 个，也可能有 2 个，或者他们可能有更多——但从来没有 1.8。

原文由 Jerry Coffin 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

在 java 中，转换错误总是报告为运行时错误。使用泛型或模板会将这些错误转化为编译时错误，从而更容易检测到您何时犯了错误。

正如我上面所说。这并不是说所有的选角都是不好的。但如果有可能避免它，最好这样做。

原文由 Mike Miller 发布，翻译遵循 CC BY-SA 2.5 许可协议