Antwort.

Die Verteilung ist ein Mechanismus zur Auswahl einer bestimmten Funktion (Methode) zum Aufruf. In Rust gibt es zwei Ansätze: statische und dynamische Verteilung.

Geschichte des Themas:

In objektorientierten Programmiersprachen wird für den dynamischen Methodenaufruf in der Regel eine vtable (virtuelle Tabelle) verwendet. In Rust wird ein ähnliches Konzept für Trait-Objekte genutzt — Verweise auf Objekte von Typen, die bestimmte Traits implementieren. Statische Verteilung tritt bei der Verwendung von Generics und Trait-Bounds auf.

Problem:

Häufig muss man zwischen Flexibilität (der Möglichkeit, mit Objekten verschiedener Typen über ein einziges Interface zu arbeiten) und Leistung (statische Verteilung ermöglicht das Inlining von Methoden) wählen. Eine falsche Wahl führt entweder zu übermäßig komplexen Generics oder zu Leistungsverlusten.

Lösung:

Statische Verteilung wird durch Generics-Parameter erreicht: Der Compiler generiert dabei separaten Code für jeden Typ. Dynamisch — wenn eine Funktion ein Argument vom Typ &dyn Trait oder Box<dyn Trait> akzeptiert, schaut Rust beim Aufruf der Methode über das Trait in die vtable an der Adresse, wie in klassischen objektorientierten Sprachen.

Beispielcode:

trait Shape {
    fn area(&self) -> f64;
}

impl Shape for Circle {
    fn area(&self) -> f64 { 3.1415 * self.radius * self.radius }
}

fn print_area(shape: &dyn Shape) { // dynamische Verteilung
    println!("area = {}", shape.area());
}

// Oder statisch:
fn print_area_static<S: Shape>(shape: &S) {
    println!("area = {}", shape.area());
}

Hauptmerkmale:

dyn Trait verwendet vtable (dynamische Verteilung)
Generics werden zur Compile-Zeit aufgerufen (statische Verteilung)
Arbeiten mit unterschiedlichen Trade-offs hinsichtlich Geschwindigkeit und Flexibilität

Fangfragen.

Kann man Box<dyn Sized> machen?

Nein. dyn Trait ist definitorisch — unsized, erfordert immer die Verwendung von Box, Arc oder Verweisen, aber nicht „Box<dyn Sized>“ — das macht keinen Sinn. Sized-Traits haben keine trait objects.

Ist dyn Trait für Traits mit generischen Methoden erlaubt?

Nein. Man kann keine objekt-sicheren Traits mit generischen Methoden erstellen (häufig wird dies verwechselt!), zusammengesetzte Typen sind nicht objekt-sicher:

trait MyTrait { fn foo<T>(&self, x: T); }
let x: &dyn MyTrait = ... // Kompilierungsfehler!

Kann man dyn Trait für einen Trait mit Self-Werten in der Signatur erstellen?

Nein, wenn die Methode Self zurückgibt (viele verstehen diesen Nuance nicht: objekt Sicherheit erfordert, dass in der Signatur kein Self enthalten ist; man kann self nur in den Argumenten, aber nicht im Rückgabewert haben).

Typische Fehler und Anti-Pattern

Missbrauch von dyn Trait, wo statische Verteilung passt
Versuche, generische Methoden oder verknüpfte Typen mit dyn Trait zu verwenden (der Compiler wird es verbieten)
Unauffällige Leistungslecks in "dünnen" Bereichen (häufige Aufrufe)

Beispiel aus dem Leben

Negativer Fall

Überall wurde dyn Trait wegen der universellen Schnittstellen verwendet, selbst innerhalb enger Schleifen, wo man mit Generics auskommen konnte.

Vorteile:

Flexibilität, einfaches Erweitern der Schnittstelle ohne Neukompilierung

Nachteile:

Verluste von 15-30% bei der Leistung bei Methodenaufrufen, keine Möglichkeit zum Inlining

Positiver Fall

Statische Verteilung wurde in der internen Logik verwendet, und dyn Trait nur an den Grenzen der Module.