Skip to content

Commit b9ca99c

Browse files
author
Tom
committed
Translation
1 parent 9e04791 commit b9ca99c

File tree

1 file changed

+13
-49
lines changed

1 file changed

+13
-49
lines changed

swift-6-beta.docc/LanguageGuide/MemorySafety.md

Lines changed: 13 additions & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -149,7 +149,7 @@ increment(&stepSize)
149149
```
150150
-->
151151

152-
在上面的代码里,`stepSize` 是一个全局变量,并且它可以通常可以在 `increment(_:)` 里被访问。然而,对于 `stepSize` 的读访问与 `number` 的写访问重叠了。就像下面展示的那样,`number``stepSize` 都指向了同一个内存区域。同一块内存区域的读和写访问重叠了,因此产生了冲突。
152+
在上面的代码里,`stepSize` 是一个全局变量,并且它可以通常可以在 `increment(_:)` 里被访问。然而,对于 `stepSize` 的读访问与 `number` 的写访问重叠了。就像下面展示的那样,`number``stepSize` 都指向了同一个内存区域。针对同一块内存区域的读和写访问重叠了,因此产生了冲突。
153153

154154
![](memory_increment)
155155

@@ -184,21 +184,9 @@ stepSize = copyOfStepSize
184184
```
185185
-->
186186

187-
当你在调用 `increment(_:)` 前复制了一份 `stepSize`
187+
由于你在调用 `increment(_:)` 前复制了 `stepSize`显然 `copyOfStepSize` 会以当前 `stepSize` 的值增加。读访问在写访问开始前就结束了,所以不会产生冲突。
188188

189-
When you make a copy of `stepSize` before calling `increment(_:)`,
190-
it's clear that the value of `copyOfStepSize` is incremented
191-
by the current step size.
192-
The read access ends before the write access starts,
193-
so there isn't a conflict.
194-
195-
Another consequence of long-term write access
196-
to in-out parameters is that
197-
passing a single variable
198-
as the argument for multiple in-out parameters
199-
of the same function
200-
produces a conflict.
201-
For example:
189+
对于 in-out 参数保持长期写访问的另一个后果是,往同一个函数的多个 in-out 参数里传入同一个变量也会产生冲突。例如:
202190

203191
```swift
204192
func balance(_ x: inout Int, _ y: inout Int) {
@@ -210,7 +198,7 @@ var playerOneScore = 42
210198
var playerTwoScore = 30
211199
balance(&playerOneScore, &playerTwoScore) // OK
212200
balance(&playerOneScore, &playerOneScore)
213-
// Error: conflicting accesses to playerOneScore
201+
// 错误:playerOneScore 访问冲突
214202
```
215203

216204
<!--
@@ -242,27 +230,13 @@ balance(&playerOneScore, &playerOneScore)
242230
```
243231
-->
244232

245-
The `balance(_:_:)` function above
246-
modifies its two parameters
247-
to divide the total value evenly between them.
248-
Calling it with `playerOneScore` and `playerTwoScore` as arguments
249-
doesn't produce a conflict ---
250-
there are two write accesses that overlap in time,
251-
but they access different locations in memory.
252-
In contrast,
253-
passing `playerOneScore` as the value for both parameters
254-
produces a conflict
255-
because it tries to perform two write accesses
256-
to the same location in memory at the same time.
233+
上面的 `balance(_:_:)` 函数会将传入的两个参数平均化。将 `playerOneScore``playerTwoScore` 作为参数传入不会产生错误 —— 虽然这两个写访问在时间上重叠了,但它们访问的是不同的内存位置;相反,将 `playerOneScore` 同时传入两个参数则会冲突,因为这样会发起两次在时间上重叠、针对同一内存位置的写访问。
234+
235+
> 因为操作符也是函数,它们也会对 in-out 参数保持长时访问。例如,假设 `balance(_:_:)` 是一个名为 `<^>` 的操作符函数,那么 `playerOneScore <^> playerOneScore` 也会造成像 `balance(&playerOneScore, &playerOneScore)` 一样的冲突。
257236
258-
> Note: Because operators are functions,
259-
> they can also have long-term accesses to their in-out parameters.
260-
> For example, if `balance(_:_:)` was an operator function named `<^>`,
261-
> writing `playerOneScore <^> playerOneScore`
262-
> would result in the same conflict
263-
> as `balance(&playerOneScore, &playerOneScore)`.
264237

265-
## Conflicting Access to self in Methods
238+
239+
## 在方法中对 self 的访问冲突
266240

267241
<!--
268242
This (probably?) applies to all value types,
@@ -277,11 +251,7 @@ to the same location in memory at the same time.
277251
because, under the hood, that's exactly what happens.
278252
-->
279253

280-
A mutating method on a structure has write access to `self`
281-
for the duration of the method call.
282-
For example, consider a game where each player
283-
has a health amount, which decreases when taking damage,
284-
and an energy amount, which decreases when using special abilities.
254+
一个结构体的变值方法会在其被调用期间保持对于 `self` 的长时写访问。想象这样一个游戏:其中每个玩家都有一定的生命值,受到伤害时会减少;玩家还会有能量值,会在玩家使用特殊技能时减少。
285255

286256
```swift
287257
struct Player {
@@ -318,15 +288,7 @@ struct Player {
318288
```
319289
-->
320290

321-
In the `restoreHealth()` method above,
322-
a write access to `self` starts at the beginning of the method
323-
and lasts until the method returns.
324-
In this case, there's no other code
325-
inside `restoreHealth()`
326-
that could have an overlapping access to the properties of a `Player` instance.
327-
The `shareHealth(with:)` method below
328-
takes another `Player` instance as an in-out parameter,
329-
creating the possibility of overlapping accesses.
291+
在上面的 `restoreHealth()` 方法中,对于 `self` 的写访问开始于方法的开头,并持续到方法返回为止。在这个例子中,`restoreHealth()` 中没有任何其他的代码会对 `Player` 实例的属性产生重叠访问。但是,下面的 `shareHealth(with:)` 方法会将另一个 `Player` 实例作为 in-out 参数接受,这样则会产生重叠访问的可能性。
330292

331293
```swift
332294
extension Player {
@@ -356,6 +318,8 @@ oscar.shareHealth(with: &maria) // OK
356318
```
357319
-->
358320

321+
在上面的例子中,通过调用 `shareHealth(with:)` 方法来将
322+
359323
In the example above,
360324
calling the `shareHealth(with:)` method
361325
for Oscar's player to share health with Maria's player

0 commit comments

Comments
 (0)