問題タブ [static-cast]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
3396 参照

c++ - C++ static_cast

誰かがこの小さなコード スニペットを説明してくれませんか?

与えられた:

以下が true と評価されるのはなぜですか?

address of aこれは が と同じであると言っていaますか? もしそうなら、なぜこれは本当ですか?

0 投票する
1 に答える
10927 参照

c++ - static_cast派生クラスへのインターフェース

インターフェイスオブジェクトを、そのインターフェイスを継承する派生クラスのオブジェクトにstatic_castしようとしています。エラーが発生します

'static_cast':'IInherit*'から'cDerived*'に変換できません

派生クラスとインターフェースは次の形式です。

vector<IInherit*>getInherit()[0]のタイプがcDerived *になるように、getInherit()メソッドを介してコードでアクセスできるオブジェクトがあります。次の式を使用して静的キャストを実行しています。

static_castをインターフェースオブジェクトとして使用できるかどうかはわかりません。このキャストを実行できる他の方法はありますか?

0 投票する
0 に答える
710 参照

c++ - cocos2d-x コーディング スタイルに関する批判 - C スタイルのキャスト vs static_cast

cocos2d-x ソース コードには、以下に示すメンバー関数ポインターを処理するコードがいくつかあります。

私が集めたアイデアはmenu_selector(<MyClass>::<MyFunction>)、互換性のある関数ポインターを取得するために使用することです。しかし、C スタイルのキャストを使用すると、安全でないキャストを実行でき、未定義の動作が発生する可能性があると思います。私はここで間違っていますか?

ちょうど今、私の同僚が以下のコードに問題を抱えていました

このコードは、VS2010 で不正な変換エラーを発生させました。これは、CCObject *パラメータが必要であるためですが、IOS または Android コンパイラでは発生しません (モバイル コンパイラの古さは不明です)。私自身、同様のコードでこれをテストし、実際にVS2010でコンパイルすることができました..

私が求めているのは、の代わりにcocos2d-x使用する理由はありますか? そのような違法なキャストをすべてブロックしたでしょう。からへの変換をブロックするためですか?(TYPE)static_cast<TYPE>static_caststatic_cast(HelloWorld::*...)(CCObject::*...)

編集: による派生クラス関数ポインターの基本クラス関数ポインターへの変換はstatic_cast 合法であるように思われるため、なぜ選択するのかについてはわかりません(TYPE)

0 投票する
3 に答える
77631 参照

c++ - ポインタ型をキャストする適切な方法

次のコード(およびをVirtualAlloc()返すというvoid*事実)を考慮してください。

なぜreinterpret_cast代わりに選ばれるのstatic_castですか?

reinterpret_cast以前は、整数型(egなど)との間でポインタをキャストする場合は問題ないと思っていDWORD_PTRましたが、aからaにキャストvoid*する場合は、問題BYTE*ありませんstatic_castか?

この特定のケースに(微妙な?)違いはありますか、それとも両方とも有効なポインターキャストですか?

C ++標準にはこの場合の優先順位があり、他の方法ではなく方法を提案していますか?

0 投票する
4 に答える
2487 参照

c++ - static_cast への C++ の適切な方法

static_cast例外をスローしません。ただし、成功しない場合は、未定義の結果が生成されます。キャストが成功したかどうかを確認する最も適切な方法は何ですか?

これは役に立ちますか?

0 投票する
2 に答える
1963 参照

c++ - static_cast void* char* 対 static_cast void** char**

私が次のことをすれば、すべて問題ありません:

しかし、以下はそうではありません:

2番目の例が許可されていない理由を誰か説明してください。C++ 標準を回答全体として引用しないでください。それを引用する回答を既に見たことがありますが、その意味がわかりません。2 番目の例が機能しない理由を理解したいと思います (つまり、危険な例を挙げていただければ大変助かります)。わからないから。私にとって、どちらの例もポインターのキャストです。追加レベルの間接化によって違いが生じるのはなぜですか?

0 投票する
1 に答える
283 参照

c++ - "static_cast(from)" の場合のみ "To to{from}" か、そうでないか?

昨日、誰かの質問に答える過程で、gcc 4.7.2にの逆として定義され<type_traits>た trait template が含まれていることを発見して驚きました。std::is_explicitly_convertible<From,To>std::is_constructible_convertible<To,From>

paper-trail を検索したところ、この特性は存在しないはずであることがわかりました。その バージョンの C++11 標準ライブラリに含めることに対してバグが発生し、gcc 4.8.0 で削除されました。

そのバグ レポートは、std::is_explicitly_convertible(C++0x 標準の以前のドラフトで義務付けられていた) が2010 年にN3047によって標準ドラフトから削除されたことを指摘し ました。

N3047 は、この回り道について次のように説明しています。

残りの問題は、影響を受けたis_explicitly_convertible特性をどのように修復するかです。基本的な選択肢は次のとおりです。

  1. is_explicitly_convertible現在の式に戻って修正し、 に依存しstatic_castなくなります。is_explicitly_convertibleis_constructible
  2. 標準から削除is_explicitly_convertibleします。

最初の選択肢が検討されましたが、「明示的に変換可能」が実際に何を意味するかについて、まったく異なる理解が存在することが判明しました。がこれを正しく表現していると信じている人もstatic_castいれば、fixedis_constructibleの方がより良い意味を提供すると信じている人is_explicitly_convertibleもいます。したがって、この文書でis_explicitly_convertibleは、作業草案から を削除することをお勧めします。その特別な定義にはまだ何も依存していないため、これは今のところ害はありません。そして、その特性が依然として有用であることが判明した場合、標準の別の改訂版に追加される可能性があります.

fromこの説明は、意見の不一致の当事者が、 type の式についてFromstatic_cast<To>(from)コンパイルされるがコンパイルされないケースを知っていたことを暗示しているようTo to{from};です。またはその逆。

そのようなケースはありますか?

Fromそうでない場合、ここで機能していたtoの static_castibility と from の構築可能性の違いを正式に (投機的にではなく) 説明できToますか?ToFrom

0 投票する
1 に答える
3458 参照

qt - タイプ「QCell*」からタイプ「QWidget*」への無効な static_cast

このエラーは 4 行目に表示されます。

関数 Cells() の定義は次のとおりです。

私は何か間違ったことをしていると思うのですが、何ですか?前もって感謝します。 これがQCellのタイプで、QWidgetはQLabelの親だと思います