問題タブ [template-mixins]

背景:
当社のソフトウェアは複数の API を使用してファイル i/o を実行します: FILE*、CStdio(およびいくつかの派生物) HANDLE、...

私はFilePointer用の RAII ラッパーを作成しましたFILE*。これは、既存のすべての C コードのドロップイン置換として役立ちました。

新しいコードでは、通常、CStdio の派生クラスまたはラッパー クラスが使用されていました。

最近、SimpleTextFile以前のバージョンの MBCS に加えて、UTF-16LE I/O を処理する を作成しました。

これらのさまざまなクラスのインターフェイスは似ていますが、同一ではありません。ポリシー テンプレート クラスを使用していくつかのユーティリティ アルゴリズムを記述し、ユーティリティ アルゴリズムをさまざまなファイル タイプに適合させることができると考えました。これはある程度成功していますが、ユーティリティ アルゴリズム内で、ある種のライン リーダー フィルターを混在させる必要があることがよくあります。

そして、ここで問題が発生します-フィルター付きの行リーダーを混在させた場合、これが渡されるアルゴリズムは、ポリシークラスを使用して、基になる型に適応する方法を理解できなくなります(R現在はa Wrapper<R>、および a のポリシーは存在しませんWrapper<R>)。

質問:
既存の型に新しい動作を提供しながら、基礎となる型で機能するさまざまなポリシーを引き続き機能させることができる mixin テンプレート クラスを作成するにはどうすればよいですか?

詳細:
ポリシー テンプレート:
StreamPositionPolicy<T>- T に適合した GetPosition() および SetPosition() を 提供します。 - LineReaderPolicy<T>T から行を読み取るためのインターフェイスの汎用セットを提供します。 - TFileNamePolicy<T>に GetFilename() を提供します。

したがって、T が CStdio の派生物、または FILE* の場合、上記は、元のファイル名を探し、行を読み取り、取得するための共通のインターフェイスを提供するために最善を尽くします。

さらに、I Have:
FilteredStringReader<F,R>はフィルターをリーダーに結合します。以前は、次のようにしていました。

これは、LineReaderPolicy<> を使用するすべてのアルゴリズムでうまく機能します。これは、既定のポリシーが ReadString() インターフェイスの使用を試みることであり、このインターフェイスが既定の (汎用) ポリシーと一致し、問題がないためです。

ただし、このオブジェクトが、他のポリシーの 1 つを使用する必要があるアルゴリズムの 1 つに渡されるとStreamPositionPolicy<FilteredStringReader<F,R>>、このスキームは破綻します。StreamPositionPolicy<>aには aがなく、FilteredStringReader<>aFilteredStringReader<>はデフォルトに適合しませんStreamPositionPolicy<>(ストリーム インターフェイスや名前インターフェイスなどではなく、ライン リーダー インターフェイスのみを提供します)。

そのため、そのような mixin はおそらく CRTP を使用し、その基になるファイル タイプ/リーダー タイプから派生する必要があると考えていました。次に、それはそれらの1つであり、基礎となるリーダーに特化したポリシークラスはすべて成功します。

しかし、それは生涯/所有権/コピーの問題を引き起こします:

驚くべきことに、この種の動作 - このポリシー オブジェクトの構築は可能です... ただし、リーダー インスタンスをコピーします (リーダーの実装によっては、これは壮大なアイデアではない可能性があります。または、より可能性が高いのは、一部のリーダー タイプが単純に勝つ可能性があります)。コピーは許可されません)。

リーダー オブジェクトの 1 つのインスタンス (mixin テンプレート インスタンスによってラップされるインスタンス) だけが必要です。

だから、これは間違った道を進んでいるような気がします。

可変個引数テンプレートを利用でき、場合によっては完全転送を使用して、ミックスイン自体とそのベースをインプレースで構築できます。しかし、それは以前の化身の機能の一部を失います: 表示された元のバージョンはFilteredStringReader<F,R>、リーダーの上にレイヤー化され、使用され、その後破棄される可能性があり、リーダー自体の寿命は続きます (または、別のアルゴリズムの目的のためにより深くラップされました)。 ）。

そのため、CRTP を使用するのは適切ではないようです。しかし、それから、他のすべてをそのままにして、1つのインターフェイスだけをインターセプトするタイプRのラッパーを作成する方法という元の問題に戻りますか?

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

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

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

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

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

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

引数リスト全体を可変個引数テンプレートから継承するとします。引数はどのように継承されますか?

私はそれを試してみましたが、すべて Rが public に継承されているようです(最初のものだけではありません)。これは定義された動作ですか?

gcc と msvc で試してみました ( clang でもjaggedSpireに感謝します)、すべて同じ結果でした。コンパイラは、警告についても言及していません。ここで実行例を見ることができます。

同時に使用できるかどうかに関係なく、新しいクラスを作成するとします。明らかに、同時に呼び出される可能性があるすべてのものをロックしたくはありません。これに対処する 1 つの方法は、ロックを指定するミックスインによるパラメーター化です。

Lockingマルチスレッドの場合は実際にロックするクラスでインスタンス化し、他の場合はノーオペレーションを行うクラスでインスタンス化します (うまくいけば、コンパイラは呼び出しを最適化します)。

ここで、ロックの代わりにソフトウェア トランザクション メモリを使用してこれを行いたいとします。N3919 (またはgcc 前駆体)を見ると、考え方が異なります。などの呼び出しはありません。

代わりに、次のような関数指定子があります

およびブロック指定子のような

後者が前者を呼び出すという厳格なルールがあり、そのように見えるものはミックスインで使用できません。

これを行うにはどうすればよいですか (プリプロセッサを使用せずに)。また、STM の主な利点の 1 つはコンポーザビリティbarですが、トランザクション可能であることをインスタンス化に反映させる方法はないようです。

次のパターンに従う2セットのミックスイン基本クラスがあります

これらの基本クラスから、2 セットの mixin クラスを派生させます

私が今直面している問題は、OneArgBase パターンに従ってクラスを TwoArgMix に渡したいということです

しかし、OneArgMix パターンに従う Mixin 基本クラスに最初のテンプレート パラメーターのみを渡す場合に、TwoArgMix のコンストラクターをどのように記述するかはわかりません。これらのクラスは OneArgMix にも必要であるため、可能であれば、OneArgMix コンストラクターにダミー引数を書き込むことは避けたいと思います。