extern crate vs use in Rust: Wie man sie nicht verwechselt und richtig schreibt

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

extern crate und use in Rust: Wo liegt der Haken und wie man Fehler vermeidet

\n\n

Wenn Sie jemals auch nur ein paar Zeilen in Rust geschrieben haben, sind Sie sicherlich auf die Konstrukte extern crate und use gestoßen. Auf den ersten Blick scheinen sie dasselbe zu tun – externen Code einzubinden. Aber der Teufel steckt, wie immer, im Detail. Diese Frage gehört zu den beliebtesten auf Stack Overflow (tausende Aufrufe!), und Anfänger verwechseln sie ständig. Lassen Sie uns ein für alle Mal klären, worin sich extern crate und use unterscheiden, wo welche Magie passiert und wie man typische Fehler vermeidet.

\n\n

Das Wichtigste in Kürze: Was ist was

\n\n

Stellen Sie sich Ihr Rust-Projekt wie ein großes Haus vor. extern crate ist die Lieferung von Baumaterialien auf das Grundstück. Sie sagen dem Compiler: „Hey, diese Kiste mit Ziegeln (Crate) möchte ich verwenden, bring sie her.“ Ohne diesen Befehl weiß der Compiler nicht einmal von der Existenz einer externen Bibliothek.

\n\n

use ist die interne Navigation im Haus. Sie sagen: „Ich möchte, dass die Tür aus diesem Raum (Modul) direkt in die Küche führt (zu einem bestimmten Typ oder einer Funktion).“ use erstellt Aliase (kurze Pfade) zu bereits bekannten Modulen und Typen, damit Sie nicht jedes Mal den vollständigen Pfad schreiben müssen.

\n\n

Einfach gesagt: extern crate beantwortet die Frage „Was können wir überhaupt verwenden?“, während use die Frage beantwortet „Wie können wir am bequemsten darauf zugreifen?“.

\n\n

Historischer Kontext: Warum alle durcheinanderkommen

\n\n

Die Verwirrung ist nicht aus dem Nichts entstanden. In älteren Versionen von Rust (vor der 2018 Edition) war extern crate für jede externe Crate obligatorisch. Das sah so aus:

\n\n
// Rust 2015 – alter Stil\nextern crate serde;\nuse serde::{Serialize, Deserialize};
\n\n

Seit der Rust 2018 Edition kann der Compiler Abhängigkeiten aus der Cargo.toml selbst finden. Jetzt ist es nicht mehr nötig, für die meisten Crates extern crate zu schreiben. Es reicht, die Abhängigkeit in der Cargo.toml hinzuzufügen und sofort use zu verwenden:

\n\n
// Rust 2018+ – neuer Stil (extern crate ist nicht erforderlich)\nuse serde::{Serialize, Deserialize};
\n\n

Hier beginnt das Chaos für Anfänger. Sie sehen alte Beispiele mit extern crate, neue ohne, und versuchen zu verstehen, wann es dennoch benötigt wird. Spoiler: Es wird benötigt, aber nur in sehr seltenen Fällen.

\n\n

Wann extern crate immer noch benötigt wird (und das ist wichtig!)

\n\n

Es gibt drei Situationen, in denen Sie auf extern crate nicht verzichten können:

\n\n
    \n
  • Verknüpfung mit Systembibliotheken über #[link] – wenn Sie Bindungen zu C/C++-Code schreiben und das Attribut #[link(name = "sqlite3")] verwenden, ist extern crate obligatorisch.
  • \n
  • Globale Makros – einige Crates (z. B. log) exportieren Makros, die im gesamten Programm sichtbar sein müssen. In Rust 2018 muss man dafür extern crate log; schreiben.
  • \n
  • Kompilierung mit nicht standardmäßigen Crate-Namen – wenn Sie extern crate my_crate as foo; verwenden, um eine Crate umzubenennen.
  • \n
\n\n

In allen anderen Fällen ist extern crate ein Artefakt der Vergangenheit. Aber viele Entwickler schreiben es aus Gewohnheit weiter, und Anfänger kopieren Code aus alten Tutorials.

\n\n

Die Top-5-Fehler bei der Arbeit mit extern crate und use

\n\n

Fehler Nr. 1: Verwendung von extern crate, wo es nicht benötigt wird

\n\n

Das häufigste Problem. Sie fügen eine Crate zur Cargo.toml hinzu, schreiben dann extern crate rand; – und der Code funktioniert. Aber das ist eine überflüssige Zeile. In modernen Projekten (Rust 2018+) verstopft sie nur den Code und kann andere Entwickler verwirren.

\n\n
// Schlecht (redundant in Rust 20                

Blogs

Buchempfehlungen