問題タブ [policy-based-design]

そして皆さん、メリークリスマス！

私は静的ポリモーフィズムについて学んでおり、ポリシーベースの設計に関する Andrei Alexandrescu の優れた本を読んでいます。コードで次のことに遭遇しました。メソッドが存在する必要があることInterfaceを指定するインターフェイスがあります。Fooこのインターフェイスは、クラスによって実装されImplます。次の 2 つのオプションがあります。

1) 動的多型

2) 静的多型

この場合、静的ポリモーフィズムを使用することは理にかなっていますか? 2 番目のアプローチは、最初のアプローチと比較して利点がありますか? インターフェースはいくつかのメソッドの存在のみを指定し、そのメカニズムは異なる実装でも同じです。そのため、本で説明されているケースとはまったく異なり、物事を複雑にしすぎているだけかもしれません.

更新:実行時にポリモーフィックな動作は必要ありません。正しい実装はコンパイル時に認識されます。

ポリシーベースの設計を使用してクラスを一般化しようとしていますが、gcc は基本クラスに実装されている純粋仮想関数の実装を認識していないようです。次に例を示します。

私が得ているエラーは次のとおりです。

よくわからない問題が2つあります。

1. 関数のシグネチャがまったく同じであっても、コンパイラはAccessPolicy< ReturnType >::implementation< DataClass >...の実装とは見なして いないようです。AccessPolicy< ReturnType >::interface...
2. コンパイラーは、呼び出している operator[] を解決できませんが、それらはすべて異なる引数を持ち、size_t を明確に呼び出しています (数値を暗黙的に文字列に変換することはできません)。

なぜこれが起こっているのですか？

私の推測では、「インターフェイス」と「実装」から直接継承しているにもかかわらず、メンバー関数が何らかの形で異なる名前空間になってしまうということです。それが正しい場合、どうすればこれを回避できますか?

EDIT :リクエストに応じて、テンプレートを取り除いた上記の例を追加しました

私の現在のクラス設計は次のようなものです (クラス階層と関数呼び出しを複製しました)。

このロジックを、テンプレート化されたポリシー ベースのファクトリに置き換えようとしています。pliclyに基づいて以前にクラスを設計したことはありません。どのように設計すべきかを提案してください。

In Modern C++ Design: Generic Programming and Design Patterns AppliedAndrei Alexandrescu は、ポリシーのデストラクタを保護することを提唱しています。

デストラクタは保護されているため、ポリシー オブジェクトを破棄できるのは派生クラスだけです。そのため、部外者がポリシー クラスへのポインタに削除を適用することはできません。ただし、デストラクタは仮想ではないため、サイズや速度のオーバーヘッドはありません

しかしその後、彼はポリシーの互換性について次の段落を書いています。

ご覧のとおり、ポリシー間の変換を実装する際に両面の柔軟性があります。左側に変換コンストラクターを実装するか、右側に変換演算子を実装できます。

2 つのポリシーがあるとします。

タイプ First の一時オブジェクトを作成せずに、ポリシー Second からポリシー First への変換演算子を作成するにはどうすればよいでしょうか。

ポリシーベースのスマート ポインター クラス Ptr を考えてみましょう。ポリシーは 1 つだけで、NULL 状態での逆参照を防ぎます (何らかの方法で)。この種の 2 つのポリシーを考えてみましょう。

• NotNull
• NoChecking

ポリシーはより制限的であるため、 からへのNotNull暗黙的な変換を許可したいと思いますが、反対方向への変換は許可しません。それは安全のために明示的でなければなりません。次の実装を見てください。Ptr< T, NoChecking >Ptr< T, NotNull >

実際の例

上記のコードは、暗黙的に両方向に変換するとstd::is_convertible失敗します。つまり、クラスに互換性のあるコンストラクターがある場合でも失敗します。問題は次のとおりです。

1. コンストラクターのオーバーロードは明示的なキーワードだけでは区別できないため、ホスト クラスには明示的なコンストラクターと暗黙の変換演算子 (またはその逆) が必要です。
2. 明示的なコンストラクターの方が優れています。それ自体が暗黙的であっても、コンストラクターは初期化リストから明示的なコンストラクターを呼び出すためです。
3. デストラクタが保護されているため、暗黙的な変換演算子はポリシー タイプのオブジェクトを作成できません。これが、そうすべきではないときに失敗する理由であり、禁止されている一時的なポリシー オブジェクトを作成するため、変換演算子のstd::is_convertibleようなものを使用できない理由でもあります。boost::implicit_cast< const target_policy& >( *this )

私の意見では最適ではない明らかな解決策については、次のとおりです。

1. ポリシー デストラクタを公開し、Ptr* をポリシー* にキャストして削除するときに UB のリスクを冒しますか? これは、提供されている例ではありそうにありませんが、実際のアプリケーションでは可能です。
2. デストラクタを公開し、保護された継承を使用します。公開継承が提供する強化されたインターフェイスが必要です。

質問は：

これらの型のオブジェクトを作成しない、ある型から別の型への暗黙的なコンストラクターの存在に対する静的テストはありますか?

または、次のようにします。

ポリシーのコンストラクターをホスト クラスのコンストラクターから呼び出すときに、暗黙的な構築の情報を保持するにはどうすればよいですか?

編集：

2 番目の質問は、次のような暗黙的フラグ付きのプライベート コンストラクターを使用して簡単に回答できることに気付きました。

ただし、エラーはあまり読みにくく、ポリシーに不要な要件を導入するため、最初の質問への回答がより望ましいです。

私は、Andrei Alexandrescu によって記述されたポリシー ベースの設計に非常に感銘を受けModern C++ Design、いくつかの軽量プログラムで成功裏に試しました。ここで、実際のシステムを作成する必要がPythonあります。そのアプローチは、ここで非常に役立つと思います。ただし、このアプローチの例は、 では 1 つも見つかりませんPython。推奨されていませんか、Pythonそれともより良い代替手段がありますか? でのポリシー ベースの設計の例を教えてもらえますかPython? 私の目的はオークション システムを開発することであり、実行時にオークション戦略 ( 、 、 などEnglish)Dutchを選択できるようにしたいと考えています。Silent

Pythonとはよく似ているのでRuby、 の例でRubyもいいと思います。

私の知る限り、mixin は最初に派生クラスを作成するときであり、その後、テンプレート パラメーターを介して基底クラスをそれに注入できます。

例: http://www.drdobbs.com/cpp/mixin-based-programming-in-c/184404445

私が知っているように、ポリシーベースの設計は同じことを目的としています。 http://en.wikipedia.org/wiki/Policy-based_design

それから派生する必要があるとは言っていません。テンプレート パラメーターを他の方法で使用することもできます。ただし、たとえばウィキペディアのポリシーベースの設計例では、次のようなものです。

これは mixin と同じだと思います。（代わりに、ミックスインでは通常パブリック継承を使用します）

それらの間に大きな違いはありますか、それともミックスインはポリシーベースの設計の特別なケースですか?