ジェネリクスは、特定の型に依存しないコードを書くことを可能にします。これは、角括弧の構文を使用して実装されます:
fn max<T: PartialOrd>(a: T, b: T) -> T { if a > b { a } else { b } }
ここで T は、PartialOrd トレイトで制約されたジェネリック型です。
ジェネリックパラメーターは <T> を介して宣言されますが、トレイト境界を使用して制限できます。たとえば、<T: Display> のように。これは、必要なトレイトが実装されている型のみが使用できることをコンパイラに伝える方法です。
Rust では、ジェネリクスのための二つのディスパッチ形式が際立っています:
dyn Trait が使用される場合、仮想テーブル(vtable)を介して呼び出しが行われます。機械コードへの影響: トレイト境界を持つジェネリクスを使用すること(dyn Traitなし)はモノモーフィゼーションをもたらします:バイナリが大きくなりますが、最大の速度を得られます。dyn Trait の使用はバイナリを節約しますが、パフォーマンスが低下します。
質問: 次の関数があります。
fn do_something<T: Debug>(value: &T)
コンパイラは、使用される各型に対してバイナリコード内に異なる do_something 関数を生成しますか、またはユニバーサルな実装を使用しますか?
一般的な誤った答え: トレイト境界のおかげで、すべての型に対して1つの関数を使用します。
正しい答え: コンパイラは、各型に対してこの関数の別々のコピーを生成します(モノモーフィゼーション)。トレイト境界はジェネリック関数を vtable によって「ユニバーサル」にするわけではありません。ユニバーサリティは dyn Trait(動的ディスパッチ)を使用する場合にのみ現れます。
例:
fn print_val<T: std::fmt::Debug>(val: T) { println!("{:?}", val); } // 異なる型で呼び出すたびにそれぞれの関数のバージョンが作成されます
物語
大きなジェネリックオブジェクトを含むプロジェクトでは、バイナリファイルが予想以上に大きくなっていることが発見されました。後に判明したのは、制約のないジェネリック関数の広範な使用が原因でした。数十の型での呼び出しが実行ファイルのサイズの指数関数的な増加(コードの膨張)を引き起こし、それはCIでのリリースビルド時にのみ明らかになりました。
物語
一部の開発者は、トレイト境界を持つジェネリックパラメーターを受け入れ、このコードが「動的」ディスパッチで動作すると考えていました。これにより、サーバーのメモリ使用量が過剰になり、コードとそのキャッシュの増加によりパフォーマンスが低下しました。
物語
ライブラリでは、
Self型を持つジェネリックトレイト(たとえば、トレイトClone)をdyn Traitとして使用しようとしましたが、これはRustでサポートされておらず、コンパイルエラーが発生しました。インターフェイスを明示的に書き直す必要があり、そうでなければジェネリックAPIは動的モードでは機能せず、インターフェイスはコンパイル時レベルで変更する必要がありました。