问题标签 [static-cast]

有人可以为我解释这个小代码片段吗？

鉴于：

为什么以下评估为真？

这就是说address of a的一样a吗？如果是这样，为什么这是真的？

我在 C++ 程序中有一个枚举参数，我需要使用一个通过参数返回值的函数来获取该参数。我首先将其声明为 int，但在代码审查中被要求将其键入为枚举 (ControlSource)。我这样做了，但它破坏了 Get() 函数——我注意到 C 风格的转换为 int& 解决了这个问题，但是当我第一次尝试用 static_cast<> 修复它时，它没有编译。

为什么会这样，为什么当 eTimeSource 是 int 时根本不需要强制转换来通过引用传递整数？

我正在尝试将接口对象静态转换为继承该接口的派生类的对象。我收到一个错误

“static_cast”：无法从“IInherit *”转换为“cDerived *”

派生类和接口的格式如下。

我有一个vector<IInherit*>可通过 getInherit() 方法在代码中访问的对象，因此 getInherit()[0] 的类型是 cDerived* 我正在使用表达式执行静态转换：

我不确定是否可以将 static_cast 作为接口对象。有没有其他方法可以让我表演这个演员？

在cocos2d-x 源代码中有一些处理成员函数指针的代码，如下所示。

我收集的想法是用来menu_selector(<MyClass>::<MyFunction>)获取兼容的函数指针。但我相信使用 C 风格的转换允许他们执行不安全的转换，并导致可能的未定义行为。我在这里错了吗？

刚才我的一位同事对以下代码有疑问

这段代码在 VS2010 上给出了非法转换错误，因为CCObject *需要一个参数，但在 IOS 或 Android 编译器上却没有（我不确定移动编译器有多旧）。我自己用一些类似的代码对此进行了测试，实际上它可以用 VS2010 编译。

我要问的是，cocos2d-x使用(TYPE)而不是有原因static_cast<TYPE>吗？static_cast会阻止所有此类非法演员。是因为static_cast会阻止从(HelloWorld::*...)to 的转换(CCObject::*...)吗？

编辑：派生类函数指针到基类函数指针的转换static_cast 似乎是合法的，所以我不知道他们为什么选择(TYPE).

考虑以下代码（以及VirtualAlloc()返回 avoid*的事实）：

为什么reinterpret_cast选择而不是static_cast？

我曾经认为这reinterpret_cast对于例如将指针转换为整数类型（如 eg DWORD_PTR）是可以的，但是从 avoid*转换为 a BYTE*，不是static_cast吗？

在这种特殊情况下是否有任何（细微的？）差异，或者它们只是有效的指针转换？

C++ 标准是否对这种情况有偏好，建议一种方式而不是另一种方式？

static_cast不会抛出异常。但如果它不成功，它将产生一个未定义的结果。检查演员表是否成功的最正确方法是什么？

这会有帮助吗？

如果我执行以下操作一切正常：

但以下不是：

请有人向我解释为什么不允许第二个例子。请不要引用 C++ 标准作为您的全部答案，因为我已经看到引用它的答案，但我不明白它们的意思。我想了解为什么第二个示例不起作用（即，如果您可以举一个危险的示例，那将是一个很大的帮助）。因为我不明白。对我来说，这两个例子都是投射指针。为什么额外的间接级别会产生任何影响？

Yesterday in the course of answering someone else's question I was surprised to discover that gcc 4.7.2 <type_traits> contained the trait template std::is_explicitly_convertible<From,To>, defined as the inverse of std::is_constructible_convertible<To,From>:

Searching for paper-trail, I then discovered that this trait ought not to have been there. A bug was raised against its inclusion in that version of the C++11 Standard Library and it was removed in gcc 4.8.0.

That bug report pointed out that std::is_explicitly_convertible (having been mandated in earlier drafts of the C++0x Standard), was removed from the draft Standard by N3047 in 2010.

N3047 explains this about-turn:

The remaining question is, in which way the also affected is_explicitly_convertible trait should be repaired. The basic choices are:

1. Fix is_explicitly_convertible by returning to the current static_cast expression, no longer making is_explicitly_convertible dependent on is_constructible.
2. Remove is_explicitly_convertible from the standard.

The first choice was considered, but it turned out that there exist quite different understandings of what "explicitly convertible" should actually mean. While some believe that static_cast correctly expresses this, others believed that the fixed is_constructible would provide a better meaning for is_explicitly_convertible as well. Therefore this paper recommends to remove the is_explicitly_convertible from the working draft. This should do no harm now, because nothing depends on that special definition yet. And if it turns out, that the trait would still be useful, it could be added in another revision of the standard.

This explanation seems to imply that the parties to the disagreement knew of cases in which, for an expression from of type From, static_cast<To>(from) would compile while To to{from}; would not; or vice versa.

Are there such cases?

If not, can anyone authoritatively (not speculatively, please) explain the distinction between static_castibility of From to To and constructibility of To from From that was in play here?

此错误出现在第 4 行：

下面是函数 Cells() 的定义：

我想我做错了什么，但是什么？提前致谢。 这是 QCell 的类型，我认为 QWidget 是 QLabel 的父级

静态演员的描述说

如果 new_type 是右值引用类型，则 static_cast 将表达式的值转换为 xvalue。这种类型的 static_cast 用于在 std::move 中实现移动语义。(C++11 起)

这是否确认以下内容是等价的？

（一个）

(乙)