関係書目カスタムアロケータメモリ割り当てが常に簡単に出来るとは限りません。ほとんどの場合、Rustが既定の方法でメモリ割り当てを行いますが、割り当て方法をカスタマイズする必要が出てくる場合があります。現在、コンパイラと標準ライブラリはコンパイル時に既定のグローバルアロケータを切り替えることが出来ます。書かれていますが、ここではどのように独自のアロケータを作成するか順を追って説明します。(jemallocのないターゲットもあります)という2つの既定のアロケータを提供しています。これらのアロケータは単に普通のRustのクレートで、メモリの割り当てと解放の手続きを実装しています。標準ライブラリはどちらか一方を前提としてコンパイルされているわけではありません。コンパイラは生成する成果物の種類に応じてどちらのアロケータを使用するかをコンパイル時に決定します。この場合、コンパイラは最後のリンクにまで影響力を持っているという意味で、「全世界を支配」しています。従ってアロケータの選択はコンパイラに委ねることができます。他のアプリケーションや他の環境など、使用するアロケータの決定権がない世界において、Rustは「お客」に過ぎません。)に頼ることになります。アロケータの切り替えコンパイラによる既定の選択はほとんどの場合うまく動きますが、しばしば多少の調整が必要になることがあります。コンパイラのアロケータ選択を上書きするには、単に希望のアロケータとリンクするだけです。a);}この例で生成されるバイナリは既定のjemallocとリンクする代わりに、システムアロケータを使います。逆に既定でjemallocを使う動的ライブラリを生成するには次のようにします。a);}カスタムアロケータを書く時々jemallocとシステムアロケータの選択では足りず、全く新しいカスタムアロケータが必要になることがあります。同様のもの)を実装した独自のクレートを書くことになります。簡素な注釈付きバージョンを見てみましょう。このクレートがアロケータであることを示す必要があります。循環依存を避けるため、アロケータはアロケータを使う標準ライブラリに依存してはいけません。libcoreについては全ての機能を使用できます。カスタムアロケータに固有の名前を付けてください。同梱されているlibcクレートを使います。stableではないためです)。そのため特別に同梱版のlibcが必要になります。今のところ、カスタムアロケータには以下の5つのメモリ割り当て関数が必要です。コンパイラは現時点では関数のシグネチャとシンボル名の型検査を行いません。将来的には以下の型に一致する必要があります。渡すことができません。改良の必要があります。このAPIはlibcではサポートされていません。このクレートがアロケータであることを示す必要があります。循環依存を避けるため、アロケータはアロケータを使う標準ライブラリに依存してはいけません。libcoreについては全ての機能を使用できます。カスタムアロケータに固有の名前を付けてください。同梱されているlibcクレートを使います。stableではないためです)。そのため特別に同梱版のlibcが必要になります。今のところ、カスタムアロケータには以下の5つのメモリ割り当て関数が必要です。コンパイラは現時点では関数のシグネチャとシンボル名の型検査を行いません。将来的には以下の型に一致する必要があります。渡すことができません。改良の必要があります。このAPIはlibcではサポートされていません。size}このクレートをコンパイルすると、次のように使えるようになります。a);}カスタムアロケータの制限カスタムアロケータを使用する場合、コンパイルエラーの原因となりうるいくつかの制限があります。1つの成果物は高々1つのアロケータとしかリンクすることはできません。バイナリ、dynlib、staticlibは必ず1つのアロケータとリンクする必要があり、もし明示的に指定されなければコンパイラがアロケータを選択します。rlibはアロケータとリンクする必要はありません(リンクすることも可能です)。ついたクレートはアロケータを使うクレートに直接的にも間接的にも依存することが出来ません(例えば、循環依存は許されていません)。このためアロケータは原則としてlibcoreにしか依存しないようにする必要があります。