为什么要使用static_cast< int>（x）而不是（int）x？ [英] Why use static_cast<int>(x) instead of (int)x?
问题描述
我听说 static_cast 函数应该比C样式或简单的函数样式转换更可取。这是真的？为什么？
I've heard that the static_cast function should be preferred to C-style or simple function-style casting. Is this true? Why?
推荐答案
主要原因是经典的C语言强制转换在我们称为 static_cast<的内容之间没有区别。 >（）， reinterpret_cast<>（）， const_cast<>（）和 dynamic_cast<>（）。这四件事完全不同。
The main reason is that classic C casts make no distinction between what we call static_cast<>(), reinterpret_cast<>(), const_cast<>(), and dynamic_cast<>(). These four things are completely different.
A static_cast<>（）通常是安全的。语言中存在有效的转换，或者使之成为可能的适当的构造函数。唯一有风险的是当您放弃继承的类时；您必须通过语言外部的方式（例如对象中的标志）确保该对象实际上是您声称的对象的后代。只要检查结果（指针）或考虑到可能的例外情况（参考）， dynamic_cast<>（）是安全的。
A static_cast<>() is usually safe. There is a valid conversion in the language, or an appropriate constructor that makes it possible. The only time it's a bit risky is when you cast down to an inherited class; you must make sure that the object is actually the descendant that you claim it is, by means external to the language (like a flag in the object). A dynamic_cast<>() is safe as long as the result is checked (pointer) or a possible exception is taken into account (reference).
A reinterpret_cast<>（）（或 const_cast<>（） ）总是很危险的。您告诉编译器：相信我：我知道这看起来不像 foo （看起来好像是不可变的），但是确实如此。
A reinterpret_cast<>() (or a const_cast<>()) on the other hand is always dangerous. You tell the compiler: "trust me: I know this doesn't look like a foo (this looks as if it isn't mutable), but it is".
第一个问题是，在不查看大量分散代码并知道所有规则的情况下，几乎不可能分辨出哪个将以C样式转换发生。
The first problem is that it's almost impossible to tell which one will occur in a C-style cast without looking at large and disperse pieces of code and knowing all the rules.
让我们假设这些：
class CDerivedClass : public CMyBase {...};
class CMyOtherStuff {...} ;
CMyBase *pSomething; // filled somewhere
某处，现在，这两个编译方式相同：
Now, these two are compiled the same way:
CDerivedClass *pMyObject;
pMyObject = static_cast<CDerivedClass*>(pSomething); // Safe; as long as we checked
pMyObject = (CDerivedClass*)(pSomething); // Same as static_cast<>
// Safe; as long as we checked
// but harder to read
但是，让我们几乎可以看到相同的代码：
However, let's see this almost identical code:
CMyOtherStuff *pOther;
pOther = static_cast<CMyOtherStuff*>(pSomething); // Compiler error: Can't convert
pOther = (CMyOtherStuff*)(pSomething); // No compiler error.
// Same as reinterpret_cast<>
// and it's wrong!!!
如您所见，在不了解很多情况的情况下，没有简单的方法来区分这两种情况所有涉及的类。
As you can see, there is no easy way to distinguish between the two situations without knowing a lot about all the classes involved.
第二个问题是C样式的强制转换太难定位。在复杂的表达式中，很难看到C样式的强制转换。在没有完整的C ++编译器前端的情况下，几乎不可能编写需要定位C样式转换的自动化工具（例如搜索工具）。另一方面，搜索 static_cast<很容易
The second problem is that the C-style casts are too hard to locate. In complex expressions it can be very hard to see C-style casts. It is virtually impossible to write an automated tool that needs to locate C-style casts (for example a search tool) without a full blown C++ compiler front-end. On the other hand, it's easy to search for "static_cast<" or "reinterpret_cast<".
pOther = reinterpret_cast<CMyOtherStuff*>(pSomething);
// No compiler error.
// but the presence of a reinterpret_cast<> is
// like a Siren with Red Flashing Lights in your code.
// The mere typing of it should cause you to feel VERY uncomfortable.
这意味着，不仅C型强制转换更危险，而且更难找到所有这些，以确保它们是正确的。
That means that, not only are C-style casts more dangerous, but it's a lot harder to find them all to make sure that they are correct.
这篇关于为什么要使用static_cast< int>（x）而不是（int）x？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
