Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
int
Rust
提交
2accd295
R
Rust
项目概览
int
/
Rust
11 个月 前同步成功
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
R
Rust
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
2accd295
编写于
8月 04, 2015
作者:
I
Ivan Jager
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Fix some grammar in The Advanced Rust Programming Language
上级
eb11d65d
变更
7
隐藏空白更改
内联
并排
Showing
7 changed file
with
8 addition
and
8 deletion
+8
-8
src/doc/nomicon/atomics.md
src/doc/nomicon/atomics.md
+1
-1
src/doc/nomicon/concurrency.md
src/doc/nomicon/concurrency.md
+1
-1
src/doc/nomicon/destructors.md
src/doc/nomicon/destructors.md
+1
-1
src/doc/nomicon/drop-flags.md
src/doc/nomicon/drop-flags.md
+1
-1
src/doc/nomicon/dropck.md
src/doc/nomicon/dropck.md
+1
-1
src/doc/nomicon/send-and-sync.md
src/doc/nomicon/send-and-sync.md
+2
-2
src/doc/nomicon/unchecked-uninit.md
src/doc/nomicon/unchecked-uninit.md
+1
-1
未找到文件。
src/doc/nomicon/atomics.md
浏览文件 @
2accd295
...
...
@@ -127,7 +127,7 @@ fundamentally unsynchronized and compilers are free to aggressively optimize
them. In particular, data accesses are free to be reordered by the compiler on
the assumption that the program is single-threaded. The hardware is also free to
propagate the changes made in data accesses to other threads as lazily and
inconsistently as it wants. Most
ly
critically, data accesses are how data races
inconsistently as it wants. Most critically, data accesses are how data races
happen. Data accesses are very friendly to the hardware and compiler, but as
we've seen they offer
*awful*
semantics to try to write synchronized code with.
Actually, that's too weak.
...
...
src/doc/nomicon/concurrency.md
浏览文件 @
2accd295
...
...
@@ -7,7 +7,7 @@ an abstraction over them in a relatively uncontroversial way. Message passing,
green threads, and async APIs are all diverse enough that any abstraction over
them tends to involve trade-offs that we weren't willing to commit to for 1.0.
However the way Rust models concurrency makes it relatively easy design your own
However the way Rust models concurrency makes it relatively easy
to
design your own
concurrency paradigm as a library and have everyone else's code Just Work
with yours. Just require the right lifetimes and Send and Sync where appropriate
and you're off to the races. Or rather, off to the... not... having... races.
src/doc/nomicon/destructors.md
浏览文件 @
2accd295
...
...
@@ -120,7 +120,7 @@ enum Link {
will have its inner Box field dropped if and only if an instance stores the
Next variant.
In general this works really nice because you don't need to worry about
In general this works really nice
ly
because you don't need to worry about
adding/removing drops when you refactor your data layout. Still there's
certainly many valid usecases for needing to do trickier things with
destructors.
...
...
src/doc/nomicon/drop-flags.md
浏览文件 @
2accd295
% Drop Flags
The examples in the previous section introduce an interesting problem for Rust.
We have seen that's possible to conditionally initialize, deinitialize, and
We have seen that
it
's possible to conditionally initialize, deinitialize, and
reinitialize locations of memory totally safely. For Copy types, this isn't
particularly notable since they're just a random pile of bits. However types
with destructors are a different story: Rust needs to know whether to call a
...
...
src/doc/nomicon/dropck.md
浏览文件 @
2accd295
% Drop Check
We have seen how lifetimes provide us some fairly simple rules for ensuring
that never read dangling references. However up to this point we have only ever
that
we
never read dangling references. However up to this point we have only ever
interacted with the
*outlives*
relationship in an inclusive manner. That is,
when we talked about
`'a: 'b`
, it was ok for
`'a`
to live
*exactly*
as long as
`'b`
. At first glance, this seems to be a meaningless distinction. Nothing ever
...
...
src/doc/nomicon/send-and-sync.md
浏览文件 @
2accd295
...
...
@@ -3,7 +3,7 @@
Not everything obeys inherited mutability, though. Some types allow you to
multiply alias a location in memory while mutating it. Unless these types use
synchronization to manage this access, they are absolutely not thread safe. Rust
captures this
with
through the
`Send`
and
`Sync`
traits.
captures this through the
`Send`
and
`Sync`
traits.
*
A type is Send if it is safe to send it to another thread.
*
A type is Sync if it is safe to share between threads (
`&T`
is Send).
...
...
@@ -11,7 +11,7 @@ captures this with through the `Send` and `Sync` traits.
Send and Sync are fundamental to Rust's concurrency story. As such, a
substantial amount of special tooling exists to make them work right. First and
foremost, they're
[
unsafe traits
][]
. This means that they are unsafe to
implement, and other unsafe code can that they are correctly
implement, and other unsafe code can
assume
that they are correctly
implemented. Since they're
*marker traits*
(they have no associated items like
methods), correctly implemented simply means that they have the intrinsic
properties an implementor should have. Incorrectly implementing Send or Sync can
...
...
src/doc/nomicon/unchecked-uninit.md
浏览文件 @
2accd295
...
...
@@ -77,7 +77,7 @@ contain any `Drop` types.
However when working with uninitialized memory you need to be ever-vigilant for
Rust trying to drop values you make like this before they're fully initialized.
Every control path through that variable's scope must initialize the value
before it ends, if has a destructor.
before it ends, if
it
has a destructor.
*[This includes code panicking](unwinding.html)*
.
And that's about it for working with uninitialized memory! Basically nothing
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录