問題タブ [crtp]
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# - 再帰型パラメーター制約:Xここで、T:X‒より簡単な代替案はありますか?
自己参照(「再帰的」)タイプのパラメーター制約を追加することにより、単純なインターフェースをより複雑にすることがよくあります。たとえば、私はこれを変えるかもしれません:
の中へ:
主な利点:実装型(などSheep
)は、基本型の代わりにそれ自体を参照できるようになり、型キャストの必要性が減りました(コードの最後の行で示されています)。
これは非常に便利ですが、これらの型パラメーターの制約は直感的ではなく、より複雑なシナリオでは理解するのが非常に困難になる傾向があることにも気づきました。*)
質問:同じ効果または同様の効果を実現するが、把握しやすい別のC#コードパターンを知っている人はいますか?
*)このコードパターンは、直感的でなく、理解しにくい場合があります。たとえば、次のようになります。
宣言
X<T> where T : X<T>
は再帰的であるように見え、なぜコンパイラが無限ループに陥らないのか不思議に思うかもしれません。 「もしT
が、ならX<T>
、X<T>
は本当にX<X<…<T>…>>
。」と推論します。(しかし、制約は明らかにそのように解決されません。)実装者にとっては、の代わりにどのタイプを指定する必要があるかが明確でない場合があります
TImpl
。(制約は最終的にそれを処理します。)さまざまなジェネリックインターフェイス間のタイプパラメータとサブタイピング関係をミックスに追加すると、物事はかなりすぐに管理できなくなります。
c++ - CRTPクラスを介して継承するテンプレート化された派生クラス、基本クラスのメンバーオブジェクトへのアクセス
継承階層のもう一方の端にあるテンプレートクラスから基本クラスのメンバーのメンバー関数を呼び出そうとすると、
このエラーメッセージが表示されます:
bar
明らかに、それ自体ではなく、のメンバーのメンバー です。これは、非テンプレートの最終クラス(その数はすでに使用されており、すべて中間クラスから派生しているため、これについては何も変更したくない)や、から直接派生するテンプレートクラスでは発生しません。basis
basis
crtp
basis
ここで何が問題になっていますか?
c++ - 不思議なことに繰り返されるテンプレートパターンのリファクタリングの問題
次のコードは、g++ 4.6.1 でコンパイルできません。
エラーで
static_cast を reinterpret_cast に変更すると、コードがコンパイルされ、この場合は機能しますが、これがすべての場合に受け入れられる解決策であるかどうか疑問に思っていますか? つまり、基本クラスへのポインターがこれと同じでない場合はありますか? 親にデータメンバーがある場合、多重継承でこれが発生する可能性があると思いますか? GetBase が最初のスーパークラスである場合、this ポインターは等しいことが保証されていますか?
c++ - 継承が使用されている場合、CRTP を使用した typedef が機能しない
CTRPを使って継承関係にあるクラスに同名の型を定義する方法はありますか? 次のコードを試しましたが、error: member 'ptr_t' found in multiple base classes of different types
から取得しましたclang++
。
もちろん、次のものは問題ありません (ただし、冗長であり、DRY の原則に反します)。
CRTP を使用してこの動作を実現する方法がない場合、それが禁止されているのはなぜですか?
c++ - this と継承への参照を返す
シンタックス シュガーについては、 への参照を返したいのですthis
が、継承されると、関数は子クラスの型を返す必要があります。
演算子のせいで、ポインタを返して dynamic_cast することはできません。参照でなければなりません。
それは可能ですか?decltype(*this)
for T の使用は機能せず、どちらも機能しません (自動の場合、auto f()->decltype(*this)
理由this
はわかりませんが)
Scala では、次のように記述できます。
しかし、私の g++ はこれを受け入れません (それがバグなのか、仕様にないだけなのかわかりませんか?)
もちろん明示的な方法もありますが、C++11の機能を使えば回避できるのではないでしょうか?
c++ - インターフェイスをパラメーターとして取る CRTP と関数を使用できますか?
C++ では、ランタイム ポリモーフィズムに純粋仮想クラスがよく使用されます。
だからあなたは持っています:
そして、次のような派生クラス:
次に、次のような関数で使用できます。
ただし、これは実行時のケースであり、コンパイル時にオブジェクトがわかっている場合は、CRTP を使用することでより適切に処理できます。
IInterface をパラメーターとして受け取る関数で CRTP ベースの派生クラスを使用することは可能ですか?
c# - C# - CRTP を使用した侵入ツリー構造
私は現在、C# で侵入ツリー構造を実装する簡単な方法に取り組んでいます。私は主に C++ プログラマーなので、すぐに CRTP を使いたいと思いました。これが私のコードです:
これは機能しますが...ジェネリック型の制限を使用しているため、a_node.SetParent((T)this)を呼び出すときにキャストする必要がある理由がわかりません... C#キャストにはコストがかかります。各侵入コレクション実装でこのキャストを広めないでください...
c++ - 最後の参照であるCRTPのみを削除します
私はシミュレーションフレームワークを使用しています。生成される各パーティクルには、UserInfoオブジェクトへのポインタ用のスロットがあります(したがって、必要な情報をパーティクルに添付できます)。問題は、パーティクルが強制終了されるたびに、フレームワークがこのユーザー情報を削除することです。何百万ものパーティクルがあり、多くの場合情報が重複しているため、情報が異なる場合にのみ新しいUserInfoオブジェクトを作成したいと思います。もちろん、問題は、パーティクルが強制終了されるたびに、ポインタを持つUserInfoオブジェクトが削除されることです(同じオブジェクトが他のパーティクルにもアタッチされているかどうかは関係ありません)。
パーティクルが強制終了されたときにパーティクルがUserInfoオブジェクトを削除しないようにするには、どのような手順を実行する必要がありますか?UserInfoクラスに対して参照カウントとオーバーロード削除を行う必要があることに気付きました。ただし、これまで削除をオーバーロードしたことがないので、いくつか質問があります。
次のようなクラス階層がある場合:
クラスAでdeleteをオーバーロードしますが、VirtualUserInfoへのポインターまたはクラスBへのポインターでdeleteが呼び出された場合、機能しますか?(同様に、正しく機能するためにnewをオーバーロードするにはどうすればよいですか?新しい派生クラスごとにnewを再度オーバーロードする必要がありますか?)
不思議なことに繰り返されるテンプレートパターンを使用して、参照カウントを行うのは簡単です。このようなミックスインスタイルの方法で削除動作を含める方法はありますか?このタイプの動作を、私が作成するすべてのタイプのUserInfoに適用すると便利です。
私がやりたいことをするためのよりクールでより良い方法はありますか?
c++ - 不思議なことに繰り返されるテンプレートパターンのポリモーフィックコピー(C ++)の継承
CRTPを使用して、継承されたクラスにクローンメソッドを追加しています。次に例を示します。
しかし、Bから継承するクラスがある場合、たとえば次のようになります。
次に、clone()はdifferentB型のオブジェクトを返さず、Bを返します。differentBで新しいclone()メソッドを作成する以外に、これを修正する方法はありますか?
読んでくれてありがとう!
c++ - CRTP を使用した転送コンストラクター
CRTP を使用してテンプレート クラスを使用してクローン パターンを実装し、2 番目のテンプレート パラメーター Base を使用して複数レベルの継承を可能にしています。間接基本クラスのコンストラクターを呼び出そうとすると、コンパイラ エラーが発生します。
これまでに遭遇した唯一の解決策は、Cloneable で可変個引数テンプレート コンストラクターを使用することですが、私のコンパイラー (VC++11) はまだそれらを実装していません。