From 50ddcaa8d3728497409b0e26d71da2450bb468fe Mon Sep 17 00:00:00 2001 From: KaiserY Date: Thu, 10 Jan 2019 11:37:00 +0800 Subject: [PATCH 1/4] fix ch07-02 --- ...es-and-use-to-control-scope-and-privacy.md | 38 ++++++++++++++++--- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/src/ch07-02-modules-and-use-to-control-scope-and-privacy.md b/src/ch07-02-modules-and-use-to-control-scope-and-privacy.md index e722319..7317d62 100644 --- a/src/ch07-02-modules-and-use-to-control-scope-and-privacy.md +++ b/src/ch07-02-modules-and-use-to-control-scope-and-privacy.md @@ -2,7 +2,7 @@ > [ch07-01-mod-and-the-filesystem.md](https://github.com/rust-lang/book/blob/master/src/ch07-02-modules-and-use-to-control-scope-and-privacy.md) >
-> commit 820ac357f6cf0e866e5a8e7a9c57dd3e17e9f8ca +> commit 9d431b25ca6c7200eafe4107eb0765c088923027 Rust 的此部分功能通常被引用为 “模块系统”（“the module system”），不过其包括了一些除模块之外的功能。在本部分我们会讨论： @@ -68,10 +68,10 @@ fn main() { ```text crate - └── sound - └── instrument - └── woodwind - └── voice +└── sound + ├── instrument + │ └── woodwind + └── voice ``` 示例 7-3: 示例 7-2 中代码的模块树 @@ -270,7 +270,7 @@ mod sound { } fn breathe_in() { - // Function body code goes here + // 函数体 } } ``` @@ -369,6 +369,32 @@ fn main() { 示例 7-13: 使用 `use` 将模块引入作用域并使用绝对路径来缩短在模块中调用项所必须的路径 +在作用域中增加 `use` 和路径类似于在文件系统中创建软连接（符号连接，symbolic link）。通过在 crate 根增加 `use crate::sound::instrument`，现在 `instrument` 在作用域中就是有效的名称了，如同它被定义于 crate 根一样。现在，既可以使用老的全路径方式取得 `instrument` 模块的项，也可以使用新的通过 `use` 创建的更短的路径。通过 `use` 引入作用域的路径也会检查私有性，同其它路径一样。 + +如果希望通过 `use` 和相对路径来将项引入作用域，则与直接通过相对路径调用项有些小的区别：不同于从当前作用域的名称开始，`use` 中的路径必须以 `self` 示例 7-14 展示了如何指定相对路径来取得与示例 7-13 中使用绝对路径一样的行为。 + +文件名: src/main.rs + +```rust +mod sound { + pub mod instrument { + pub fn clarinet() { + // 函数体 + } + } +} + +use self::sound::instrument; + +fn main() { + instrument::clarinet(); + instrument::clarinet(); + instrument::clarinet(); +} +``` + +示例 7-14: 通过 `use` 和相对路径将模块引入作用域 + 当指定 `use` 后以 `self` 开头的相对路径在未来可能不是必须的；这是一个开发者正在尽力消除的语言中的不一致。 如果调用项目的代码移动到模块树的不同位置但是定义项目的代码却没有，那么选择使用 `use` 指定绝对路径可以使更新更轻松，这与示例 7-10 中同时移动的情况相对。例如，如果我们决定采用示例 7-13 的代码，将 `main` 函数的行为提取到函数 `clarinet_trio` 中，并将该函数移动到模块 `performance_group` 中，这时 `use` 所指定的路径无需变化，如示例 7-15 所示。 From 48821e22eee440b36c14825c63fe6f8747da76c2 Mon Sep 17 00:00:00 2001 From: oncealong Date: Thu, 10 Jan 2019 19:31:07 +0800 Subject: [PATCH 2/4] fix typo --- src/ch15-04-rc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ch15-04-rc.md b/src/ch15-04-rc.md index f885a7a..8c55f38 100644 --- a/src/ch15-04-rc.md +++ b/src/ch15-04-rc.md @@ -90,7 +90,7 @@ fn main() { 需要使用 `use` 语句将 `Rc` 引入作用域因为它不在 prelude 中。在 `main` 中创建了存放 5 和 10 的列表并将其存放在 `a` 的新的 `Rc` 中。接着当创建 `b` 和 `c` 时，调用 `Rc::clone` 函数并传递 `a` 中 `Rc` 的引用作为参数。 -也可以调用 `a.clone()` 而不是 `Rc::clone(&a)`，不过在这里 Rust 的习惯是使用 `Rc::clone`。`Rc::clone` 的实现并不像大部分类型的 `clone` 实现那样对所有数据进行深拷贝。`Rc::clone` 只会增加引用计数，这并不会花费多少时间。深拷贝可能会花费很长时间。通过使用 `Rc::clone` 进行引用计数，可以明显的区别深拷贝类的克隆和增加引用计数类的克隆。当查找代码中的性能问题时，只需考虑神拷贝类克隆而无需考虑 `Rc::clone` 调用。 +也可以调用 `a.clone()` 而不是 `Rc::clone(&a)`，不过在这里 Rust 的习惯是使用 `Rc::clone`。`Rc::clone` 的实现并不像大部分类型的 `clone` 实现那样对所有数据进行深拷贝。`Rc::clone` 只会增加引用计数，这并不会花费多少时间。深拷贝可能会花费很长时间。通过使用 `Rc::clone` 进行引用计数，可以明显的区别深拷贝类的克隆和增加引用计数类的克隆。当查找代码中的性能问题时，只需考虑深拷贝类的克隆而无需考虑 `Rc::clone` 调用。 ### 克隆 `Rc` 会增加引用计数 From 1192f6ccdeaa75a5b2ba787876c1c6f6b955e8b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=AE=A1=E6=96=8C=E7=91=9E?= Date: Sat, 12 Jan 2019 16:09:55 +0800 Subject: [PATCH 3/4] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E2=80=9C=E6=8A=BD?= =?UTF-8?q?=E8=B1=A1=E5=87=BA=E2=80=9D=E4=B8=BA=E2=80=9C=E6=8A=BD=E8=B1=A1?= =?UTF-8?q?=E6=8E=89=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit > This abstracts away some of the commonplace code so it’s easier to see the concepts that are unique to this code, such as the filtering condition each element in the iterator must pass. 这边应该是剔除冗杂代码的意思吧。 --- src/ch13-03-improving-our-io-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ch13-03-improving-our-io-project.md b/src/ch13-03-improving-our-io-project.md index 3c9adb1..e360bc2 100644 --- a/src/ch13-03-improving-our-io-project.md +++ b/src/ch13-03-improving-our-io-project.md @@ -170,6 +170,6 @@ pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { 回忆 `search` 函数的目的是返回所有 `contents` 中包含 `query` 的行。类似于示例 13-19 中的 `filter` 例子，可以使用 `filter` 适配器只保留 `line.contains(query)` 返回 `true` 的那些行。接着使用 `collect` 将匹配行收集到另一个 vector 中。这样就容易多了！尝试对 `search_case_insensitive` 函数做出同样的使用迭代器方法的修改吧。 -接下来的逻辑问题就是在代码中应该选择哪种风格：是使用示例 13-28 中的原始实现还是使用示例 13-29 中使用迭代器的版本？大部分 Rust 程序员倾向于使用迭代器风格。开始这有点难以理解，不过一旦你对不同迭代器的工作方式有了感觉之后，迭代器可能会更容易理解。相比摆弄不同的循环并创建新 vector，（迭代器）代码则更关注循环的目的。这抽象出了那些老生常谈的代码，这样就更容易看清代码所特有的概念，比如迭代器中每个元素必须面对的过滤条件。 +接下来的逻辑问题就是在代码中应该选择哪种风格：是使用示例 13-28 中的原始实现还是使用示例 13-29 中使用迭代器的版本？大部分 Rust 程序员倾向于使用迭代器风格。开始这有点难以理解，不过一旦你对不同迭代器的工作方式有了感觉之后，迭代器可能会更容易理解。相比摆弄不同的循环并创建新 vector，（迭代器）代码则更关注循环的目的。这抽象掉那些老生常谈的代码，这样就更容易看清代码所特有的概念，比如迭代器中每个元素必须面对的过滤条件。 不过这两种实现真的完全等同吗？直觉上的假设是更底层的循环会更快一些。让我们聊聊性能吧。 From e89c9507a3e68bb719c6eec393f09fffdb71de4b Mon Sep 17 00:00:00 2001 From: KaiserY Date: Tue, 15 Jan 2019 10:29:21 +0800 Subject: [PATCH 4/4] Create .gitattributes --- .gitattributes | 1 + 1 file changed, 1 insertion(+) create mode 100644 .gitattributes diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..1d1ce11 --- /dev/null +++ b/.gitattributes @@ -0,0 +1 @@ +*.md linguist-detectable=true