問題タブ [static-cast]

static_cast<>Cスタイルのキャスティングよりも好む理由はありますか？それらは同等ですか？速度の違いはありますか？

私の知る限り、ポインター/参照 static_cast の場合、この時点でクラス定義がコンパイラーに表示されない場合、 のstatic_castように動作しますreinterpret_cast。

static_castポインタ/参照に対して安全ではなく、数値に対して安全なのはなぜですか?

static_cast を使用して double* を int* にキャストしようとすると、次のエラーが発生します。

コードは次のとおりです。

double と int の間の変換に問題があることは理解していますが、double* と int* の間の変換に問題があるのはなぜですか?

カスタムクラスのStudentオブジェクトの配列があります。CourseStudentとResearchStudentはどちらもStudentを継承しており、Studentのすべてのインスタンスはこれらのいずれかです。

配列を調べて、各Studentのサブタイプを判別し、それらに対してサブタイプ固有のメンバー関数を呼び出す関数があります。

問題は、これらの関数がオーバーロードされていないため、Studentで見つからないため、コンパイラーが大騒ぎすることです。

Studentへのポインターがある場合、そのStudentのサブタイプへのポインターを取得する方法はありますか？コンパイル時のエラーを回避するために、ここで何らかの偽のキャストを作成する必要がありますか？

5.2.9 静的キャストの文言を理解している限り、void*-to-to-object-pointer 変換の結果が許可されるのはvoid*、最初に逆変換の結果であった場合のみです。

void標準全体を通して、ポインターの表現や、ポインターの表現と同じポインターの表現などへの参照がたくさんありますが、任意のポインターをキャストするとポインターが生成charされると明示的に述べているようには見えません。voidメモリ内の同じ場所に、異なる型で、オブジェクトの実際の型に戻らないタイプのパニングが未定義であるのと同じように。

そのため、適切なメモリのアドレスなどをmalloc明確に返しますが、私が見た限りでは、実際にそれを移植可能に利用する方法はないようです。

数分前に質問に答えていたところ、別の質問が浮かびました。

私のプロジェクトの 1 つで、ネットワーク メッセージの解析を行っています。メッセージの形式は次のとおりです。

ペイロードの形式と内容は、メッセージ タイプによって決まります。共通の class に基づくクラス階層がありますMessage。

Message*メッセージをインスタンス化するために、メッセージの種類に応じてbyteを返す静的解析メソッドがあります。何かのようなもの：

サブクラスのメソッドにアクセスする必要がある場合があります。私のネットワーク メッセージ処理は高速でなければならないので、回避することに決め、メッセージ タイプを返すdynamic_cast<>基本クラスにメソッドを追加しました。Messageこの戻り値に応じて、static_cast<>代わりに右の子型に a を使用します。

私がこれを行った主な理由は、これdynamic_cast<>は遅いと言われたことがあるからです。ただし、それが実際に何をするのか、どのくらい遅いのかは正確にはわかりません。したがって、私の方法は同じくらい遅い (または遅い) かもしれませんが、はるかに複雑です。

このデザインどう思いますか？それは一般的ですか？を使用するよりも本当に速いdynamic_cast<>ですか？1回の使用で内部で何が起こるかについての詳細な説明dynamic_cast<>は大歓迎です!

- - 編集 - -

一部の人々が理由を尋ねたので：

基本的に、フレームを受信すると、次の 2 つのことを行います。

1. Messageメッセージを解析し、フレームのコンテンツが有効である場合、対応するサブクラスのインスタンスを構築します。解析部分以外にロジックはありません。
2. 私は を受け取り、にMessage応じて適切なタイプに移動し、メッセージに対して必要な処理を行います。switch(message->getType())static_cast<>

Qt のソース コードを熟読しているときに、この宝石に出会いました。

static_cast<T>(0)->Type?に注意してください。私は長年 C++ を使用してきましたが、static_cast で 0 が使用されているのを見たことがありません。このコードは何をしていて、安全ですか?

背景: から派生するQGraphicsItem場合は、それと呼ばれる一意の列挙値を宣言し、それを返すTypeという仮想関数を実装することを意図しています。type

その後、これを行うことができます：

これはおそらく、 static_cast が何をしようとしているのかを説明するのに役立ちます。

ブラウザヘルパーオブジェクトに関するこのサンプルコードを理解しようとしています。

内部では、作成者は複数のインターフェイス（IObjectWithSite、IDispatch）を公開する単一のクラスを実装します。

彼のQueryInterface関数は次のことを実行します。

Cの観点からは、インターフェイスポインターはVTableへの単なるポインターであることを学びました。つまり、C++はstatic_castを使用して実装されたインターフェイスのVTableを返すことができるということです。

これは、この方法で構築されたクラスがメモリ内に多数のVTable（IObjectWithSite、IDispatchなど）を持っていることを意味しますか？C ++は、さまざまなインターフェイス（それぞれにQueryInterface、AddRef、およびRelease関数があります）での名前の衝突をどのように処理しますか？これらのそれぞれに異なるメソッドを実装できますか？

したがって、Void*からType*に、またはType*からVoid*に変換する場合は、次を使用する必要があります。

また

私にはstatic_castの方が正しいように見えますが、両方が同じ目的で使用されているのを見てきました。また、変換の方向も重要です。つまり、私はまだstatic_castを次の目的で使用する必要があります：

C ++スタイルのキャストに関する他の質問を読みましたが、このシナリオの正しい方法がまだわかりません（static_castだと思います）

コールバック関数のコードを記述する必要があります (ATL 内から呼び出されますが、それはそれほど重要ではありません)。

ここで、void*は へのポインタであることが保証されているCMyClassため、static_cast合法です。私の懸念は、コードが (少なくとも新しいバージョンの Visual C++ に対して) 可能な限り移植可能でなければならないということです。だから超偏執的になるために、私はCMyClass*ポインタもチェックする傾向があります - つまり、それがnullであることが判明した場合はどうなりますか?

2番目のチェックは合理的ですか？static_castnull 以外のポインターを null ポインターに変えることは可能ですか?