2

私はapplied C ++ブックのテンプレートについて読んでいますが、以下のように言及されています

テンプレートはコードの肥大化を引き起こします。コンパイラは、ピクセル タイプごとにテンプレート オブジェクトをインスタンス化します。ユーザーが必要とするタイプが限られている場合でも、画像処理ルーチンでは、一時的な画像などのために追加のタイプが必要になる場合があります。

オブジェクトをテンプレート化する必要がないことには、オブジェクトのコンパイル方法を制御できるという利点があり、コードの肥大化を制御できます。

上記のテキストに関する私の質問

  1. 「ユーザーが限られたタイプしか必要としない場合でも、画像処理ルーチンには一時的な画像などのために追加のタイプが必要になる場合があります」とはどういう意味ですか? ?

  2. 「テンプレート化されたオブジェクトである必要がないことには、オブジェクトのコンパイル方法を制御できるという利点があります」という著者の意味は何ですか?

上記の説明を理解するためにあなたの助けを求めてください。簡単な例で説明すると良いでしょう。

お時間をいただきありがとうございます。

4

1 に答える 1

2

著者は、テンプレートがいわゆるcode-bloatを作成する可能性があることは正しいですが、彼の説明はあいまいです...

コードの肥大化についての入門書から始めましょう。

C++ 標準では、テンプレートと関数ポインターの間に厄介な相互作用があります。

  • 指定された一連のパラメーターを持つテンプレートの各インスタンス化は、独自の型です
  • 2 つの異なる関数は異なるアドレスを持つ必要があります

2 つの異なるインスタンス化 (1 つは withintと 1 つは withlongなど) は異なるタイプであるため、それらに関連付けられた関数は異なる関数であり、したがって異なるアドレスが必要です。

最適化コンパイラは、as-if ルールの下で関数を実際にマージすることが許可されています。プログラマーがそれらがマージされたことを認識できない場合です。単純な試みは、そのうちの 1 つのアドレスが取得されないことを証明しようとすることです。これは無駄です。より巧妙な戦略は、関数本体をマージすることですが、それでも別のアドレスを提供します:

; assembly-like code
function_instantiation_1:
    nop                   ; offset to have different addresses
function_instantiation_2:
                          ; body of both functions

ただし、実際の問題は、膨大な数の関数が存在することを考えると、マージできる関数を特定することです。

そう ？生成されるコードの量を制限したい場合は、インスタンス化の数を制限するだけです。画像処理ルーチンが一時的な画像などのために追加の型を必要とするかもしれないという著者の主張は疑わしいと思います。プログラム内のタイプのセットは一般にかなり制限されており、無数の画像タイプはありません。

于 2013-08-05T06:53:02.420 に答える