相关Regular cast vs. static_cast vs. dynamic_cast一个问题：C++的类型转换风格
投什么风格的语法，你用C++喜欢？
(int)foostatic_cast<int>(foo)int(foo)他们可能不翻译成一模一样的指令（是吗？）但他们的效果应该是一样的（对吧？）。
如果你只是在内建的数字类型之间进行转换，我觉得C++风格的转换语法太冗长了。作为以前的Java编程人员，我倾向于使用C风格的转换语法，但我的本地C++ guru坚持使用构造函数语法。
您认为如何？
这是最好的做法从未使用C-风格转换主要有三个原因：
由于palm3D指出：
我觉得C++ - 风格转换语法太冗长。
这是故意的，出于上述原因。
构造函数语法（正式名称：函数样式转换）是语义相同作为C样式转换，应避免使用，以及（除了在声明变量初始化），出于同样的原因。即使对于定义自定义构造函数的类型来说，这是否应该是真实的，但在Effective C++中，Meyers认为，即使在这些情况下，您也应该避免使用它们。为了说明：
void f(auto_ptr<int> x);
f(static_cast<auto_ptr<int> >(new int(5))); // GOOD
f(auto_ptr<int>(new int(5)); // BAD
这里的static_cast实际上将调用auto_ptr构造。
C风格的转换语法，不要错误检查。 C++风格的转换语法，做一些检查。 使用static_cast时，即使它不检查，至少你知道你应该在这里小心。
`static_cast`总是检查源和目标类型是否兼容。 （如果他们将基础转换为派生类型时，它不能保护用户免受他们的错误，但这是他们的错。） – 2017-05-12 23:42:16
C风格演员是最糟糕的路要走。很难看到，无法解释，将不应混淆的不同动作混为一谈，并且无法完成C++风格演员所能做的所有事情。他们真的应该从语言中删除C风格的演员。
我使用static_cast有两个原因。
当然C++ - 风格。额外的打字将有助于防止在您不应该投射时:-)
关于此主题，我遵循Scott Meyers（More Effective C++，条款2：优先选择C++风格演员）所作的建议。
我同意C++风格的类型转换很繁琐，但是这就是我喜欢他们，他们很容易被发现，他们使代码更易于阅读（这是比写作更重要）。
他们还迫使你想想你需要什么样的演员，并选择了正确的一个，减少失误的风险。它们还将帮助您在编译时检测错误，而不是在运行时检测错误。
我们目前在任何地方都使用C风格的演员阵容。我问了另一个casting question，我现在看到使用static_cast的好处，如果没有其他原因而不是它的“greppable”（我喜欢这个词）。我可能会开始使用它。
我不喜欢C++风格;它看起来太像一个函数调用。
寻找C++风格，更糟糕的是，包含C++显式类型转换的丑陋冗长的代码片断将不断提醒我们所知道的东西（例如，显式投射是不好的 - 导致咒骂）。 如果您想掌握跟踪运行时错误的技巧，请不要使用C++风格。
构造函数的语法。 C++是OO，存在构造函数，我使用它们。 如果您觉得需要注释这些转换ctor的话，您应该为每种类型而不仅仅是内置转换。也许你使用'explicit'关键字进行转换，但客户端语法模仿了内置类型的ctor语法。 可能是可以接受的，这可能是事实，但输入更多字符会让搜索变得容易，这是多大的惊喜。为什么把这些视为特殊？ 如果你正在写大量的int/unsigned/...以及来自double/float - graphics的数学公式，并且你需要每次写一个static_cast，公式的外观变得混乱，而且非常难以理解。 无论如何，这是一场艰苦的战斗，因为很多时候你会转换，甚至没有注意到你是。 对于向下转换指针，我确实使用了static_cast，默认情况下不存在这样做。
我想知道您在代码中搜索了多少次演员自动化工具... – Blindy 2010-12-05 05:08:53
@盲目：它发生了。我已经做到了。请记住，在C++中，与其他一些语言（Java，C＃）不同，您通常可以编程而不用强制转换。代码中的每一个明确的转换都是潜在的设计缺陷。识别C++代码中的强制转换是重构中的一个重要步骤。在C＃中，在代码中搜索代码当然是荒谬的 - 它们无处不在！ – 2010-12-05 10:30:17