問題タブ [crtp]

私は単純な古い CRPT を持っています (アクセス制限に気を取られないでください - 問題はそれらについてではありません):

これは通常、次のように使用することを目的としています。

今それは私をstatic_cast悩ませます。(アップキャストではなく) ダウンキャストが必要なので、明示的なキャストを使用する必要があります。現在のオブジェクトが実際に派生クラスであるため、妥当なすべてのケースでキャストは有効です。

しかし、どうにかして階層を変更し、キャストが無効になったらどうしますか?

この場合、明示的なダウンキャストが有効であることをコンパイル時にチェックすることはできますか?

私はJavaジェネリックを最新の状態にしています（JDK 1.4 ... 1.3でもレガシーコードで長い間働いてきました）が、これをよく理解していません：

Fooとは 2 つのジェネリックBarクラスです。

よく分からないのでどう解釈すればいいですか？

私は Java ジェネリックについて多くのことを読んできましたが、これは少し頭を悩ませます (少なくとも初心者の私にとっては)。

ウィキペディアの記事で、静的 (コンパイル時) ポリモーフィズムを行うための C++ での奇妙に繰り返されるテンプレート パターンについて読みました。派生型に基づいて関数の戻り値の型を変更できるように、それを一般化したかったのです。(基本型はテンプレート パラメーターからの派生型を認識しているため、これは可能であるように思われます)。残念ながら、次のコードは MSVC 2010 を使用してコンパイルできません (現在 gcc に簡単にアクセスできないため、まだ試していません)。理由を知っている人はいますか？

ところで、追加のテンプレート パラメータを使用する回避策がありますが、私はそれが好きではありません。多くの型を継承チェーンに渡すと非常に冗長になります。

編集：

この状況で MSVC 2010 が表示するエラー メッセージは次のとおりです。error C2039: 'value_type' : is not a member of 'derived<T>'

g++ 4.1.2 ( codepad.org経由) によるとerror: no type named 'value_type' in 'class derived<int>'

CRTP の使用を検討しているパフォーマンス クリティカルなコードがあります。私の質問は、ほとんどのコンパイラがコードをどの程度最適化できるかということです。特に、コンパイラが（適切な場合に）メソッドをインライン化できるかどうか疑問に思っています。たとえば、次のコードでは:

への呼び出しと同じパフォーマンスをobject.interface()もたらす呼び出しobject.implementation()

多重継承を使用して、一種の CRTP (それが何であるかをよく理解している場合) を実装しようとしています。

私の主な目標は、各サブクラスのインスタンスのリストにアクセスするための統一された方法を持つことです。

名前空間の使用率に問題があるようです。

これが最も単純なバージョンのコードです: http://ideone.com/rFab5

私の本当の問題は、http: //ideone.com/U7cAfに似てい ます。

clang++ を使用して追加の警告があります:

名前空間を使用すると同じように動作しないため、問題が更新されました。

Ideone にコードを投稿するために再編集された問題

いくつかの場所で繰り返されるネストされたif/switchステートメントがたくさんあるプログラムがあります。私はそれを抽出してスイッチをテンプレートメソッドクラスに入れ、クライアントがオーバーロードを使用して具体的に処理したいスイッチブランチをオーバーロードできるようにしました。

ただし、これはコンパイルに失敗し（少なくともClientMergeFooTwoの場合）、Foo＆をSpecificFoo＆に変換できないと言います。で完全に優れた一般的なオーバーロードを選択する代わりに、その変換が失敗する理由はありMergeFooますか？

編集：まあ、この擬似コードの例は、私がそれを書き込もうとした速さを考えると、明らかにうまくいきませんでした。私はいくつかの間違いを訂正しました...

CRTPは、virtual機能を完全に凌駕するのに十分な能力がありますか？

CRTPで私が目にする唯一の欠点は、繰り返し発生するパターンごとに生成されるコードの量が注目に値することです。小規模な設計（2〜3クラスがベースから派生している場合）の場合、CRTPの方が適していますか？

CRTP to avoid dynamic polymorphismでは、仮想メンバー関数のオーバーヘッドを回避し、特定のインターフェイスを課すために、次の解決策が提案されています。

ただし、派生クラスは定義を継承するため、コンパイルするための定義は必要ないようです (コードは、my_type::foo を定義しなくても正常にコンパイルされます)。実際、関数が提供されている場合、派生クラスを使用するときに基本関数は呼び出されません。

問題は、次のコード置換が受け入れられるかどうか (そして標準かどうか) です。

C＃で次のCRTPタイプを指定します。

F＃でジェネリック型の定義を取得するにはどうすればよいですか？

エラーが発生します：

型推論変数にデフォルトの型'DataProviderBase<'a>'を適用すると、型制約が一致しません。''a'と'DataProviderBase<'a>'を統合すると、結果の型は無限になります。さらに型制約を追加することを検討してください。

C＃では、次のようになります。

アップデート

回避策を見つけました：

余分なタイプなしでそれを行う別の方法はありますか？

すべてのプロパティが null 許容型でなければならないクラスがあります。新しいプロパティがnull許容型を持っていることを確認するために、Sessionsクラスプロパティの設計時(実行時ではない)の検証を追加することは可能ですか? プロパティに nulable 型がない場合、コンパイラはエラーを発生させ、コードをコンパイルしないようにする必要があります。