Named Parameter IdiomとBoost::Parameter libraryの両方を見てきました。それぞれに他に比べてどのような利点がありますか? 常にどちらか一方を選択する正当な理由はありますか、または状況によってはそれぞれが他方よりも優れている可能性がありますか (そうであれば、どのような状況ですか)?
6 に答える
名前付きパラメーター イディオムの実装は非常に簡単で、Boost::Parameter を使用するのとほぼ同じくらい簡単です。
-ブースト依存関係は既にありますか? そうしないと、Boost::parameter は依存関係を追加する価値があるほど特別ではありません。
個人的には、製品コードで Boost::parameter を見たことがありません。100% の場合、名前付きパラメーターのカスタム実装でしたが、それは必ずしも良いことではありません。
通常、私は Boost の大ファンですが、いくつかの理由から Boost.Parameter ライブラリは使用しません。
- 何が起こっているのかわからない場合、呼び出しは、呼び出しを行う前に、呼び出し元の関数のスコープ内の変数に値を代入しているように見えます。それは非常に混乱する可能性があります。
- そもそもセットアップに必要な定型コードが多すぎます。
別のポイントとして、私は名前付きパラメーターのイディオムを使用したことはありませんが、最大 20 個のオプションの引数を定義するためにブースト パラメーターを使用しました。そして、私のコンパイル時間は非常識です。以前は数秒かかっていた作業が、現在では 30 秒かかります。これは、boost パラメータを使用して作成した 1 つの小さなアプリケーションを使用するもののライブラリがある場合に加算されます。もちろん、私はそれを間違って実装しているかもしれませんが、それ以外は本当に気に入っているので、これが変わることを願っています.
名前付きパラメーターの慣用句は、はるかに単純です。Boost::Parameter ライブラリの複雑さが必要な理由が (今のところ) わかりません。(想定される「機能」推定パラメーターでさえ、コーディングエラーを導入する方法のようです;))
おそらく、一般的なアプリケーション ロジックに Boost.Parameter を使用する必要はありませんが、開発中のライブラリ コードに使用すると、ライブラリのクライアントの時間を大幅に節約できます。
どちらも聞いたことがありませんが、リンクを確認すると、名前付きパラメーターの方がはるかに簡単でわかりやすくなっています。私はブーストの実装よりもハートビートでそれを選びます。