問題タブ [boost-parameter]

Named Parameter IdiomとBoost::Parameter libraryの両方を見てきました。それぞれに他に比べてどのような利点がありますか? 常にどちらか一方を選択する正当な理由はありますか、または状況によってはそれぞれが他方よりも優れている可能性がありますか (そうであれば、どのような状況ですか)?

Boost Parameterチュートリアルを使用して、トランプ ジェネレーター用の名前付きパラメーター コンストラクターを作成しています。チュートリアルでは ArgumentPack を基本クラスに入れるように書かれていますが、カード ジェネレーター クラスの変数を変更したいと考えています。私はこれを行うことを考えました:

これは合法ですか、それとも CardGenerator のプライベート変数を操作してブースト パラメータ ライブラリを使用するより良い方法はありますか? OS: Windows XP Pro、コンパイラ: Visual C++ 2008 Express、ブースト: 1.39.0

このサイトのほとんどの人は、次の 2 つの方法で実装を外部委託できることに同意すると思います。

• 私的遺産
• 構成

継承は、ほとんどの場合悪用されます。特に、パブリック継承は、別のフォームまたは継承の方が優れている可能性がある場合によく使用され、一般に、プライベート継承ではなく合成を使用する必要があります。

もちろん、通常の警告が適用されますが、実装の問題のために継承が本当に必要な場合はいつでも思いつきません。

ただし、Boost パラメータ ライブラリの場合、名前付きパラメータ イディオム (コンストラクタ用) の実装のために、構成よりも継承が選択されていることに気付くでしょう。

私が見ることができる仮想メソッドがここで動作していないため、古典的な EBO (Empty Base Optimization) の説明しか思い浮かびません。

誰かがよく知っているか、私を議論にリダイレクトできますか?

ありがとう、マチュー。

名前付きパラメーターをコンストラクターに提供するために、Boost.Parameter ライブラリーを使用します。

通常windowFunctionはオブジェクトでコピーされるのboost::functionですが、 で参照渡しもできるようにしたいですboost::ref。

boost::refただし、が削除された関数オブジェクトを渡すreference_wrapper<T>と、ArgumentPack にはT値への参照が含まれます。

質問:reference_wrapper<T>ラッパーの除去を防ぐ方法はありますか?

例：

の代わりにのコンストラクターでに渡さSomeFunctionObject& sれます。したがって、コピーされることは望ましくありません。mWindowFunClassAImplconst reference_wrapper<SomeFunctionObject>&sboost::function

プログラムの安全性を向上させるために、Booststrongtypedefユーティリティをよく使用します。たとえば、次のようなコードを記述します。

ここでの強力なtypedefは、コードの可読性と安全性の両方を向上させます。（引数が間違った順序で提供された場合、コンパイラーはエラーを報告します。これは、引数がすべての場合には当てはまりませんでしたint。）

私の質問は次のとおりです。

• この目的でBOOST_STRONG_TYPEDEFを使用しても大丈夫ですか？（ドキュメントは非常に簡潔です。）
• 代わりにブーストパラメータライブラリを好む重要な理由はありますか？

Boost の signal2 ライブラリは、その拡張機能の一部について代替パラメータを渡すための優れた方法を定義しています (そのパラメータ ライブラリを介して)。これらの代替パラメーターの 1 つが私のコードでかなり一般的である場合、使用をさらに簡素化するヘルパーを作成したいと思います。たとえば、別のミューテックス タイプを指定するには、次のようにします。

残念ながら、これを行うことで、冗長な構文に戻ったり、 my_signal_with_combiner などの追加のメタ関数を定義したりすることなく、他のシグナルパラメーター (コンバイナータイプなど) の代替値を指定する機能も「失って」しまいました (これはばかげているようです)。 . コンバイナーのデフォルトでは、戻り値の型を取得するために署名を分解する必要があるため、デフォルトのテンプレートパラメーター値でもそれを行うことはできないと思います。(もちろん、理想的には、コンバイナーだけでなく、他のパラメーターのいずれかで機能するものが欲しいです。)

したがって、「本当の」質問は次のとおりです。それと同じように動作するが、パラメーターの1つに異なるデフォルト値を持つsignal_typeのようなものを定義する（簡単な）方法はありますか？(理想的には、Boost.Signals2 が将来さらにパラメーターを追加する場合、変更する必要はありません。)

(また、C++11 は使用しないでください。まだ古いコンパイラを使用しています。)

警告：問題を説明するために、先に長い紹介が必要です。VandevoordeとJosuttisの16.1章で最初に説明された名前付きテンプレート引数イディオムは、Boost.Parameterライブラリを使用して簡単に記述できます。

上記のコードを使用すると、のオプションのテンプレートパラメータに名前を付けて任意の順序でオーバーライドできBreadSlicerます。これにより、多くのデフォルトパラメータを使用したポリシーベースの設計が非常に便利になります。Policy1_isPolicy2_is

ポリシーベースの設計での非常に微妙なODR違反を回避するために（説明については、Alexandrescuによるこの古い投稿を参照してください）、名前付きテンプレート引数にCRTPパターンを適用できるようにしたいと思います。

ただし、一部の内部static_assertが（VC10 SP1）のようなメッセージで失敗するため、上記のBoost.Parameter実装はコンパイルに失敗します。

'main :: CuriousBreadSlicer'：コンパイラの組み込み型特性'__is_base_of'への引数として未定義のクラスは許可されていません

質問：この静的チェックをオフにすることはできますか？マクロまたはテンプレートのトリックのいずれかを介して？

考えられる回避策について：

1. 上記のコードは、この手書きコードと機能的に同等です。そのコードでは、CRTPパターンが機能します。ただし、Boost.Parameterライブラリが便利に自動化する多くの定型コードが必要です。
2. CRTPパラメーターを常にテンプレート引数のリストの最初に配置し、 Policy1_isクラスでラップしないようにすることができます。これにより、コンパイル時のエラーは解決されますが、オーバーライドの順序に依存しなくなります。

ですから、私はゴルフ選手が「クラブの間」と呼んでいるもののようです。どのソリューションが最適ですか？

Boost (実際には Boost Graph Library) を使用するのはかなり初めてで、最初のグラフ アルゴリズムを作成しようとしています。私のアルゴリズムでは、いくつかのオプションおよびデフォルト設定可能なパラメータを渡す必要があるため、Boost::Parameter ライブラリを使用しようと考えました。私が理解しているように、これは、BGL で広く使用されている古い BGL 名前付きパラメーター システムに対する改善です。

ここのチュートリアルから作業しています。チュートリアルの最初の単純なサンプルは正常に動作しますが、述語要件を使用してパラメーターがアルゴリズムの前提条件と一致することを確認しようとすると、理解できないコンパイラ エラーが多数発生します。

次のテスト コードは、チュートリアルの述語チェックの例を簡略化したものです。

コンパイラからのエラー メッセージは次のとおりです。

テンプレート パラメーター 'T2' のテンプレート引数として使用できません。実際の型のエラーが予想されます C2955: 'boost::is_convertible': クラス テンプレートの使用にはテンプレート引数リスト エラーが必要です C2065: '_': 宣言されていない識別子エラー C2955: 'boost ::graph_traits': クラス テンプレートの使用にはテンプレート引数リストが必要です エラー C2065: '_': 宣言されていない識別子エラー C2955: 'boost::graph_traits': クラス テンプレートの使用にはテンプレート引数リストのエラーが必要です C1903: 前のエラーから回復できません( s); コンパイルの停止 クラス テンプレートを使用するにはテンプレート引数リストが必要です エラー C2065: '_': 宣言されていない識別子エラー C2955: 'boost::graph_traits': クラス テンプレートを使用するにはテンプレート引数リストが必要です エラー C1903: 以前のエラーから回復できません。コンパイルの停止 クラス テンプレートを使用するにはテンプレート引数リストが必要です エラー C2065: '_': 宣言されていない識別子エラー C2955: 'boost::graph_traits': クラス テンプレートを使用するにはテンプレート引数リストが必要です エラー C1903: 以前のエラーから回復できません。コンパイルの停止

問題は、boost::graph_traits<_>::traversal_category のような行の括弧で囲まれたアンダースコアと関係があると思います

ただし、何が起こっているのか本当にわかりません。問題を修正する方法についてアドバイスをいただければ幸いです。これに関するより多くのコード サンプルとユーザー ドキュメントへのポインタも非常に役立ちます。パラメータ ライブラリは非常に強力に見えます。効果的な使用方法を学ぶために時間を費やす準備ができています。

Microsoft Visual Studio 2010 で Boost 1.47 を使用しています。

最近、Boostにパラメータライブラリが見つかりました。正直なところ、これがBoostの一部である理由がわかりませんでした。関数にいくつかのパラメーターを渡す必要がある場合は、次のようにそれらから構造を作成できます。

これは非常に書きやすく、理解しやすいものです。ブーストパラメータを使用した例：

本当に複雑で、メリットはそれほど重要ではないと思います。

しかし、Boostライブラリ（Asio）の一部がこの手法を使用していることがわかりました。このライブラリを使用して多くの引数を渡すことがベストプラクティスと見なされますか？

それとも、私には見えないこのライブラリを使用することの本当の利点がありますか？プロジェクトでこのライブラリを使用することをお勧めしますか？

現在、いくつかのファクトリ関数で boost.parameter を使用しており、コンパイル時間が法外になっています。

現在、次のような一般的なパターンがあります。

wheremakeThingには 30 個のパラメータがあり、そのほとんどはデフォルトです。「名前付きパラメーターのような」構文と、位置ではなくタイプでパラメーターを一致させる機能を保持したいと思います。

ファクトリの呼び出しサイトで構文を変更せずにコンパイル速度を向上させるにはどうすればよいですか?

注: boost.MPL の速度と言う盗賊の速度の違いから判断すると、最新のメタ プログラミング手法が同等の boost.parameter で使用された場合、コンパイル時間は少なくとも 1 桁は改善されるはずです。

更新:これはまさに私がやっていることの要約された例です: ベアメタルの組み込みコンテキストでは、ポリシーベースのクラス設計イディオムに従って、複雑なテンプレート化されたクラスとして抽象化されたさまざまな周辺機器があります。各クラスはコンパイル時に多くの構成情報を取得し、必要な機能のみを使用します (すべての SFR 相互作用は監視可能であり、揮発性であるため許可されないため、未使用のものを取り除くためにオプティマイザーに頼ることはできません)。

これらのポリシーベースのクラスは、ユーザーが構成するのが非常に醜く、ほとんどの組み込みユーザーは、パブリック インターフェイスで < を見ると叫び声を上げて逃げるので、boost.parameter を使用して、タイプ エンコードされたすべてのウィッシュを渡すことができるセクシーなファクトリを作成します ( hana スタイルのように) 必要な ISR に接続し、ハンドルを返すローカルの静的としてクラスを生成します。

ほとんどのファクトリには 10 ～ 25 個のパラメーターがあり、プリプロセッサ時間が致命的なようです。ユーザーが実際に関数を呼び出すかどうかに関係なく、ファクトリごとに 1 ～ 5 秒かかります。

更新 2:報奨金は終了したため、解決策はないようです。時間があれば、boost.parameter の置き換えを作成し、ここにリンクします。また、boost.hana スタイルのセマンティクスに近づけるために、名前付きパラメーター関数の戻り値の型を入力の型に依存させるとよいでしょう。