問題タブ [dynamic-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.
c++ - dynamic_cast<> を回避する方法は、dynamic_cast<> 自体よりも高速ですか?
数分前に質問に答えていたところ、別の質問が浮かびました。
私のプロジェクトの 1 つで、ネットワーク メッセージの解析を行っています。メッセージの形式は次のとおりです。
ペイロードの形式と内容は、メッセージ タイプによって決まります。共通の class に基づくクラス階層がありますMessage
。
Message*
メッセージをインスタンス化するために、メッセージの種類に応じてbyteを返す静的解析メソッドがあります。何かのようなもの:
サブクラスのメソッドにアクセスする必要がある場合があります。私のネットワーク メッセージ処理は高速でなければならないので、回避することに決め、メッセージ タイプを返すdynamic_cast<>
基本クラスにメソッドを追加しました。Message
この戻り値に応じて、static_cast<>
代わりに右の子型に a を使用します。
私がこれを行った主な理由は、これdynamic_cast<>
は遅いと言われたことがあるからです。ただし、それが実際に何をするのか、どのくらい遅いのかは正確にはわかりません。したがって、私の方法は同じくらい遅い (または遅い) かもしれませんが、はるかに複雑です。
このデザインどう思いますか?それは一般的ですか?を使用するよりも本当に速いdynamic_cast<>
ですか?1回の使用で内部で何が起こるかについての詳細な説明dynamic_cast<>
は大歓迎です!
- - 編集 - -
一部の人々が理由を尋ねたので:
基本的に、フレームを受信すると、次の 2 つのことを行います。
Message
メッセージを解析し、フレームのコンテンツが有効である場合、対応するサブクラスのインスタンスを構築します。解析部分以外にロジックはありません。- 私は を受け取り、に
Message
応じて適切なタイプに移動し、メッセージに対して必要な処理を行います。switch(message->getType())
static_cast<>
templates - typeid 、動的キャスト (アップキャスト)、およびテンプレート
動的キャスト 、 typeid() 、およびテンプレートに関していくつか質問があります
1) なぜ typeid は RTTI を必要としないのですか?
2) ポリモーフィック型の dynamic_cast:
RTTI でダウンキャスト (ベースから派生) を行うと、コンパイルがパスします
RTTI がオフの場合 - 警告が表示されます (警告 C4541: 'dynamic_cast' used on polymorphic type 'CBase' with /GR-; unpredictable behavior may result)
- アップキャスト (ベースへの派生) を行う場合、RTTI の有無にかかわらず - コンパイルはスムーズに行われます
私が理解していないのは、アップキャストを実行し、RTTI がオフになっていると、警告/エラーが表示されない理由です!
3) NON ポリモーフィック型の dynamic_cast:
- RTTI の有無にかかわらずダウンキャストを行うと、コンパイルが失敗します (エラー C2683: 'dynamic_cast' : 'CBase' はポリモーフィック型ではありません)
しかし
- RTTI の有無にかかわらずアップキャストを行うと、コンパイルはスムーズに行われます。
RTTI なしで NON ポリモーフィック タイプ パスのアップキャストが発生するのはなぜですか?
4) テンプレート関数の前にある「インライン」には何らかの効果がありますか? つまり、コンパイラが関数をコンパイルして「インライン」であると判断した場合、関数は実際にはインラインとして扱われますか、それとも無視されますか?
デビッドを助けてくれてどうもありがとう
c++ - 条件付きでオブジェクトのタイプを変更する
dynamic_castingに少し問題があります。実行時にオブジェクトのタイプを判別する必要があります。これがデモです:
上記をやりたいと思います。私がそれを行うために見つけた唯一の合法的な方法は、事前にすべてのオブジェクトを定義することです。
これに関する主な問題は(使用されないオブジェクトの束を定義する必要があることを除いて)、「person」変数の名前を変更する必要があることです。もっと良い方法はありますか?
(クラス(Person、Lawyer、またはDoctor)は、私のコードを使用する人々が持っているライブラリの一部であり、変更したくないため、変更することはできません)。
ありがとう、
デイブ
c++ - dynamic_cast の継承と使用
次のような 3 つのクラスがあるとします (これは例であるため、コンパイルされません!)。
実行時まで利用できない設定に応じて、Derived1 または Derived2 のインスタンスを作成したいと考えています。
実行時まで派生型を判断できないため、次のことは悪い習慣だと思いますか?...
私は一般的に、dynamic_cast の使用法が悪いと読んでいますが、前述したように、実行時までどのタイプを作成すればよいかわかりません。助けてください!
java - クラスキャスト例外
私は次のようにJavaに2つのクラスがあります:
コンパイル時にはエラーは発生しませんが、実行時にはエラーが表示されます: Exception in thread "main" java.lang.ClassCastException: A cannot be cast to B
objective-c - isMemberOfClassと==のクラスの比較
次の間に実際の違いはありますか?
オブジェクトであるかどうかを確認するvalue
には?SomeClass
java - 動的キャスト:同等のクラスと文字列
私の問題を言葉で表現しようとする代わりに、私がやりたいことを示すコードを次に示します。
何か案は?リフレクションの使用を検討しましたが、成功しませんでした。
c++ - テンプレート化されたクラスに void* を dynamic_cast できません
私が得ている正確なエラーは次のとおりです。
'object' (タイプ 'void*') をタイプ 'class udDator(int)*' に dynamic_cast できません (ソースはクラスへのポインタではありません)
これは、オーバーライドされたオペレーターの削除内で発生しています。参照を通じてメモリを管理し、他のクラスに継承できるテンプレート化されたメモリ管理クラスを作成しようとしています。これは、スマートな shared_ptr のようなものの代わりになり、メモリ管理をさらに目立たなくする試みであり、余分な入力は必要ありません ( shared_ptr< someClass > shared( new someClass() ) はちょっと長い... )。
とにかく、ここに関連するコードがあります。詳細について言及するのを忘れた場合、または確認する必要があるコードがない場合は、お知らせください。
オーバーライドされた演算子:
テンプレート化されたクラス:
テンプレート化されたクラスの使用法:
c++ - 独自のdynamic_castの書き方
これはインタビューで尋ねられました。
独自のdynamic_castを作成する方法。typeidのname関数に基づいていると思います。
では、独自のtypidを実装する方法は?私にはそれについての手がかりがありません。
c++ - 派生クラスでの仮想関数の実装での dynamic_cast の回避
これは、私が達成しようとしていることを説明するサンプルコードです。
基本的に、クラスで利用可能ないくつかの基本的な操作に依存するアルゴリズムがあります。これらの操作は、純粋な抽象基本クラスで定義しました。特定のオブジェクトのクラスを派生させることにより、そのアルゴリズムをさまざまなオブジェクトに適用して、それらの操作を提供したいと考えています。
ただし、これらの操作に関する限り、異なる派生オブジェクトは互いに互換性がありません。私の質問は、RTTI の使用を避けて、たとえば、ブール派生 2::同一 (const base* other2)、アサート (または他の終了メカニズム) で、other2 が派生 2 型ではないことを確認できるかどうかです。
1 つの代替手段は、特定の派生オブジェクトで関数アルゴリズムをテンプレート化することですが、それは実装がヘッダー ファイルに存在する必要があることを意味します。これは、1) テスト目的でアルゴリズム コードを変更すると、コードの大部分の再コンパイル 2) アルゴリズムの実装は、エンドユーザーから隠されているソース ファイルに適切に存在するのではなく、ヘッダーで公開されます。