C ++强制转换语法样式

与常规投放，static_cast和dynamic_cast相关的问题：

在C ++中，您更喜欢哪种转换语法样式？

• C样式转换语法：(int)foo
• C ++样式转换语法：static_cast(foo)
• 构造函数语法：int(foo)

它们可能不会翻译成完全相同的指令(是吗？)，但是它们的效果应该是相同的(是吗？)。

如果只是在内置数字类型之间进行转换，我会发现C ++样式的转换语法太冗长。 作为前Java编码器，我倾向于使用C样式强制转换语法，但是我的本地C ++专家坚持使用构造函数语法。

你怎么看？

---

最好不要使用C样式转换，这是三个主要原因：

• 如前所述，此处不执行检查。程序员根本不知道使用了哪种类型的转换会削弱强类型
• 新的演员阵容在视觉上是有目的的。由于强制转换通常会揭示代码中的弱点，因此有人认为使强制转换在代码中可见是一件好事。
• 如果使用自动化工具搜索演员表，则尤其如此。可靠地找到C型演员表几乎是不可能的。

如palm3D所述：

I find C++-style cast syntax too verbose.

由于上述原因，这是有意的。

构造函数语法(正式名称：函数样式转换)在语义上与C样式转换相同，并且出于相同的原因，也应避免使用(声明中的变量初始化除外)。即使对于定义自定义构造函数的类型是否应如此，也存在争议，但在有效C ++中，Meyers认为即使在这种情况下，也应避免使用它们。为了显示：

此处的static_cast实际上将调用auto_ptr构造函数。

---

根据Stroustrup：

The"new-style casts" were introduced
to give programmers a chance to state
their intentions more clearly and for
the compiler to catch more errors.

因此，确实是安全的，因为它会进行额外的编译时检查。

---

关于此主题，我遵循Scott Meyers的建议("更有效的C ++，第2项：更喜欢C ++样式的强制转换")。

我同意C ++样式转换很冗长，但这就是我喜欢它们的原因：它们非常容易发现，并且它们使代码更易于阅读(比编写更重要)。

他们还迫使您考虑需要哪种类型的演员，并选择正确的演员，以减少出错的风险。它们还将帮助您在编译时而不是在运行时检测错误。

---

绝对是C ++风格的。多余的输入将有助于防止您在不应该使用时进行转换：-)

---

我使用static_cast有两个原因。

很明显正在发生什么。如果不了解是否正在进行强制转换，我将无法继续阅读。使用C型演员表时，您的视线可以不停地经过它。

在我要转换的代码中搜索每个位置都很容易。

---

构造函数语法。 C ++是OO，构造函数存在，我使用它们。
如果您需要注释这些转换ctor，则应该对每种类型都进行注释，而不仅仅是内置类型。 也许您将'explicit'关键字用于转换ctor，但客户端语法完全模仿内置类型的ctor语法。
可以抓住，这可能是正确的，但是键入更多字符使搜索变得很容易，这是一个很大的惊喜。 为什么将这些视为特殊？
如果您要编写带有往返于double / float(图形)和int / float(图形)之间的int / unsigned / ...的数学公式，并且每次都需要编写static_cast，则该公式的外观会变得混乱并且非常难以理解。
无论如何，这都是一场艰苦的战斗，因为很多时候您甚至都没有意识到自己会转变。
对于向下转换的指针，我确实使用static_cast，因为默认情况下，当然不存在会这样做的ctor。

---

追求C ++风格，更糟糕的是，构成C ++显式类型转换的丑陋冗长的代码片段将不断提醒我们所知道的内容(即显式转换很糟糕-导致造词的产生)。
如果您想掌握跟踪运行时错误的技巧，请不要使用C ++风格。

---

目前，我们到处都使用C样式转换。我问了另一个强制转换问题，现在我看到了使用static_cast的好处，如果不是因为它是"可抓取的"(我喜欢这个术语)，就别无选择。我可能会开始使用它。

我不喜欢C ++风格；它看起来太像一个函数调用。

---

C样式转换是最糟糕的选择。很难看到，无法理解，将不应该合并的不同动作组合在一起，并且不能完成C ++样式转换可以执行的所有操作。他们确实应该从该语言中删除C样式的强制转换。

---

C样式强制转换语法，请勿进行错误检查。
C ++样式的强制转换语法，进行一些检查。
使用static_cast时，即使它不进行检查，至少您知道在此也要小心。

---