fix translation

Author: dalance

1.6/ja/book/custom-allocators.md

@@ -7,7 +7,7 @@
 <!-- out the default global allocator in use at compile time. The design is currently -->
 <!-- spelled out in [RFC 1183][rfc] but this will walk you through how to get your -->
 <!-- own allocator up and running. -->
-メモリ割り当ては常に簡単に出来るとは限りません。通常はRustが既定の方法でメモリ割り当てを行いますが、しばしば割り当て方法をカスタマイズする必要が出てきます。現在、コンパイラと標準ライブラリはコンパイル時に既定のグローバルアロケータを切り替えることが出来ます。詳細は[RFC 1183][rfc]に書かれていますが、ここではどのように独自のアロケータを作成するか順を追って説明します。
+メモリ割り当てが常に簡単に出来るとは限りません。ほとんどの場合、Rustが既定の方法でメモリ割り当てを行いますが、割り当て方法をカスタマイズする必要が出てくる場合があります。現在、コンパイラと標準ライブラリはコンパイル時に既定のグローバルアロケータを切り替えることが出来ます。詳細は[RFC 1183][rfc]に書かれていますが、ここではどのように独自のアロケータを作成するか順を追って説明します。
 
 [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1183-swap-out-jemalloc.md
 
@@ -21,7 +21,7 @@
 <!-- allocate and deallocate memory. The standard library is not compiled assuming -->
 <!-- either one, and the compiler will decide which allocator is in use at -->
 <!-- compile-time depending on the type of output artifact being produced. -->
-現在コンパイラは`alloc_system`と`alloc_jemalloc`(いくつかのターゲットにはありません)という2つの既定のアロケータを提供しています。これらのアロケータは単に普通のRustのクレートで、メモリの割り当てと解放の手続きが実装されています。標準ライブラリはどちらか一方を前提としてコンパイルされているわけではなく、生成する成果物の種類に応じてどちらのアロケータを使用するかをコンパイラが決定します。
+現在コンパイラは`alloc_system`と`alloc_jemalloc`(いくつかのターゲットにはありません)という2つの既定のアロケータを提供しています。これらのアロケータは単に普通のRustのクレートで、メモリの割り当てと解放の手続きを実装しています。標準ライブラリはどちらか一方を前提としてコンパイルされているわけではありません。コンパイラは生成する成果物の種類に応じてどちらのアロケータを使用するかをコンパイル時に決定します。
 
 <!-- Binaries generated by the compiler will use `alloc_jemalloc` by default (where -->
 <!-- available). In this situation the compiler "controls the world" in the sense of -->
@@ -34,15 +34,15 @@
 <!-- cannot authoritatively decide what allocator is in use. As a result it resorts -->
 <!-- back to the standard APIs (e.g. `malloc` and `free`) for acquiring and releasing -->
 <!-- memory. -->
-一方、動的あるいは静的ライブラリの場合、既定では`alloc_system`を使用します。他のアプリケーションや使用するアロケータの決定権がない他の世界において、通常Rustは「お客」です。そのため、メモリの割り当てと解放を行うには、標準API(例えば`malloc`と`free`)に頼らざるを得ません。
+一方、動的あるいは静的ライブラリの場合、既定では`alloc_system`を使用します。他のアプリケーションや他の環境など、使用するアロケータの決定権がない世界において、Rustは「お客」に過ぎません。そのため、メモリの割り当てと解放を行うには、標準API(例えば`malloc`と`free`)に頼ることになります。
 
 <!-- # Switching Allocators -->
 # アロケータの切り替え
 
 <!-- Although the compiler's default choices may work most of the time, it's often -->
 <!-- necessary to tweak certain aspects. Overriding the compiler's decision about -->
 <!-- which allocator is in use is done simply by linking to the desired allocator: -->
-コンパイラの既定の選択はほとんどの場合うまく動きますが、しばしば多少の調整が必要になることがあります。コンパイラのアロケータ選択を上書きするには、単に希望のアロケータをリンクするだけです。
+コンパイラによる既定の選択はほとんどの場合うまく動きますが、しばしば多少の調整が必要になることがあります。コンパイラのアロケータ選択を上書きするには、単に希望のアロケータとリンクするだけです。
 
 ```rust,no_run
 
@@ -51,6 +51,7 @@
 extern crate alloc_system;
 
 fn main() {
+    let a = Box::new(4); // allocates from the system allocator
     let a = Box::new(4); // システムアロケータからのメモリ割り当て
     println!("{}", a);
 }
@@ -59,7 +60,7 @@ fn main() {
 <!-- In this example the binary generated will not link to jemalloc by default but -->
 <!-- instead use the system allocator. Conversely to generate a dynamic library which -->
 <!-- uses jemalloc by default one would write: -->
-この例では生成されるバイナリは既定のjemallocにリンクするのではなく、システムアロケータを使います。逆に既定でjemallocを使う動的ライブラリを生成するには次のようにします。
+この例で生成されるバイナリは既定のjemallocとリンクする代わりに、システムアロケータを使います。逆に既定でjemallocを使う動的ライブラリを生成するには次のようにします。
 
 ```rust,ignore
 #![feature(alloc_jemalloc)]
@@ -68,6 +69,7 @@ fn main() {
 extern crate alloc_jemalloc;
 
 pub fn foo() {
+    let a = Box::new(4); // allocates from jemalloc
     let a = Box::new(4); // jemallocからのメモリ割り当て
     println!("{}", a);
 }
@@ -82,28 +84,28 @@ pub fn foo() {
 <!-- crate which implements the allocator API (e.g. the same as `alloc_system` or -->
 <!-- `alloc_jemalloc`). As an example, let's take a look at a simplified and -->
 <!-- annotated version of `alloc_system` -->
-時々jemallocとシステムアロケータの選択では足りず、全く新しいカスタムアロケータが必要になることがあります。この場合、アロケータAPI(例えば`alloc_system`や`alloc_jemalloc`と同様の)を実装した独自のクレートを書くことになります。例として、`alloc_system`の簡素な注釈付きバージョンを見てみましょう。
+時々jemallocとシステムアロケータの選択では足りず、全く新しいカスタムアロケータが必要になることがあります。この場合、アロケータAPI(例えば`alloc_system`や`alloc_jemalloc`と同様のもの)を実装した独自のクレートを書くことになります。例として、`alloc_system`の簡素な注釈付きバージョンを見てみましょう。
 
 ```rust,no_run
 # // only needed for rustdoc --test down below
 # #![feature(lang_items)]
 // The compiler needs to be instructed that this crate is an allocator in order
 // to realize that when this is linked in another allocator like jemalloc should
 // not be linked in
-// コンパイラにjemallocのような他のアロケータにリンクすべきでないと理解させるため、
+// コンパイラがリンク時に他のアロケータ(例えばjemalloc)とリンクしてしまうことを防ぐため、
 // このクレートがアロケータであることを示す必要があります。
 #![feature(allocator)]
 #![allocator]
 
 // Allocators are not allowed to depend on the standard library which in turn
 // requires an allocator in order to avoid circular dependencies. This crate,
 // however, can use all of libcore.
-// 循環依存を避けるため、アロケータがアロケータを要求する標準ライブラリに依存することは出来ません。
-// しかしlibcoreは全て使用できます。
+// 循環依存を避けるため、アロケータはアロケータを使う標準ライブラリに依存してはいけません。
+// しかしlibcoreについては全ての機能を使用できます。
 #![no_std]
 
 // Let's give a unique name to our custom allocator
-// カスタムアロケータ固有の名前を付けてください。
+// カスタムアロケータに固有の名前を付けてください。
 #![crate_name = "my_allocator"]
 #![crate_type = "rlib"]
 
@@ -112,7 +114,7 @@ pub fn foo() {
 // to the standard library (e.g. `#![no_std]` isn't stable yet), so that's why
 // this specifically requires the in-tree version.
 // この独自アロケータはFFIバインディングのためにin-treeのlibcクレートを使います。
-// 注記: 現在の外部(crate.io)libcは標準ライブラリにリンクしているため使用できません
+// 注記: 現在の外部libc(crate.ioのもの)は標準ライブラリとリンクしているため使用できません
 // (`#![no_std]`がまだstableではないためです)。そのため特別にin-treeのlibcが必要になります。
 #![feature(libc)]
 
@@ -137,6 +139,7 @@ pub extern fn __rust_reallocate(ptr: *mut u8, _old_size: usize, size: usize,
 #[no_mangle]
 pub extern fn __rust_reallocate_inplace(_ptr: *mut u8, old_size: usize,
                                         _size: usize, _align: usize) -> usize {
+    old_size // this api is not supported by libc
     old_size // このAPIはlibcではサポートされていません。
 }
 
@@ -161,6 +164,7 @@ pub extern fn __rust_usable_size(size: usize, _align: usize) -> usize {
 extern crate my_allocator;
 
 fn main() {
+    let a = Box::new(8); // allocates memory via our custom allocator crate
     let a = Box::new(8); // カスタムアロケータによるメモリ割り当て
     println!("{}", a);
 }
@@ -177,11 +181,11 @@ fn main() {
 <!--   dylibs, and staticlibs must link to exactly one allocator, and if none have -->
 <!--   been explicitly chosen the compiler will choose one. On the other hand rlibs -->
 <!--   do not need to link to an allocator (but still can). -->
-* 1つの成果物は高々1つのアロケータにしかリンクすることはできません。バイナリ、dynlib、staticlibは必ず1つのアロケータにリンクする必要があり、もし明示的に指定されなければコンパイラが選択します。一方、rlibはアロケータにリンクする必要はありません(リンクすることも可能です)。
+* 1つの成果物は高々1つのアロケータとしかリンクすることはできません。バイナリ、dynlib、staticlibは必ず1つのアロケータとリンクする必要があり、もし明示的に指定されなければコンパイラがアロケータを選択します。一方、rlibはアロケータとリンクする必要はありません(リンクすることも可能です)。
 
 <!-- * A consumer of an allocator is tagged with `#![needs_allocator]` (e.g. the -->
 <!--   `liballoc` crate currently) and an `#[allocator]` crate cannot transitively -->
 <!--   depend on a crate which needs an allocator (e.g. circular dependencies are not -->
 <!--   allowed). This basically means that allocators must restrict themselves to -->
 <!--   libcore currently. -->
-* アロケータを使うコードは`#![needs_allocator]`でタグ付けされ(例えば`liballoc`クレート)、`#[allocator]`(訳注: `#![allocator]`のtypo?)がついたクレートはアロケータを使うクレートに依存することは出来ません(循環依存は許されていません)。このためアロケータは今のところlibcoreにしか依存しないようにする必要があります。
+* アロケータを使うコードは`#![needs_allocator]`でタグ付けされます(例えば現時点での`liballoc`クレート)。また、`#[allocator]`がついたクレートはアロケータを使うクレートに依存することが出来ません(循環依存は許されていません)。このためアロケータは原則としてlibcoreにしか依存しないようにする必要があります。