0

次のように、テンプレート クラス/関数が入力型の明示的なメンバーに頻繁にアクセスするライブラリがあります。

template <
typename InputType>
bool IsSomethingTrue(
  InputType arg1) {

  typename InputType::SubType1::SubType2 &a;

  //Do something

}

ここで、SubType1SubType2は、それ自体が をインスタンス化するために使用されたジェネリック型ですInputType。for に渡すのに有効なライブラリ内のすべての型をすばやく見つける方法はありますかInputType( forSubType1およびSubType2)? これまでのところ、適切なメンバーを含むクラスのコード ベース全体を検索してきましたが、テンプレートの入力名は多くの場所で再利用されるため、非常に面倒です。

コーディングの観点からすると、おそらく既に定義されている有効な入力タイプのセットが限られている場合に、このようなテンプレートを使用する意味は何ですか? この関数をジェネリックにするのではなく、明示的な型でオーバーロードしないのはなぜですか?

4

2 に答える 2

2

コーディングの観点から、おそらくすでに定義されている有効な入力タイプのセットが限られている場合に、このようなテンプレートを使用する意味は何ですか?この関数を汎用にするのではなく、明示的な型でオーバーロードしないのはなぜですか?

まず第一に、それらのオーバーロードはまったく同じボディ、または非常に類似したボディを持つためです。関数の本体が十分に長い場合、関数のバージョンを増やすことはメンテナンスの問題になります。アルゴリズムを変更する必要がある場合は、N回変更する必要があり、間違いを犯さないことを願っています。ほとんどの場合、冗長性は悪いです。

さらに、現在は関数の構文要件を満たすそのようなタイプがいくつかある可能性がありますが、将来的にはさらに増える可能性があります。関数テンプレートを使用すると、新しいタイプが1つ導入されるたびに新しいオーバーロードを作成しなくても、アルゴリズムを新しいタイプで機能させることができます。

于 2013-03-13T20:04:50.593 に答える
0

ジェネリック型を使用する利点は、テンプレート側にはありません。明示的に名前を付けて、毎回テンプレートコードを編集する場合は、同じです。

ただし、テンプレートで受け入れられるタイプのサブクラスまたはバリアントを導入するとどうなりますか?もう一方の端に変更は必要ありません。

つまり、すべてのタイプが事前にわかっていると言えば、コードの変更と拡張を除外していることになります。これは、テンプレートを使用する場合の半分のポイントです。

于 2013-03-13T20:04:38.547 に答える