Skip to content

Commit 052a760

Browse files
committed
Merge branch 'mr/github/86' into 'master'
docs: fix some typos See merge request eng/toolchain/gnatcoll-core!141
2 parents f66b0f8 + c774680 commit 052a760

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

docs/refcount.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6,11 +6,11 @@
66

77
Memory management is often a difficulty in defining an API. Should we let
88
the user be responsible for freeing the types when they are no longer needed,
9-
or can we do it automatically on his behalf ?
9+
or can we do it automatically on his behalf?
1010

1111
The latter approach is somewhat more costly in terms of efficiency (since
1212
we need extra house keeping to know when the type is no longer needed), but
13-
provides an easier to use API.
13+
it provides an easier to use API.
1414

1515
Typically, such an approach is implemented using reference counting: all
1616
references to an object increment a counter. When a reference disappears,
@@ -71,7 +71,7 @@ it can get tricky: when there is a cycle between two reference counted objects
7171
(one includes a reference to the other, and the other a reference to the
7272
first), their counter can never become 0, and thus they are never freed.
7373

74-
There are, however, common design patterns where this can severly interfer:
74+
There are, however, common design patterns where this can severly interfere:
7575
imagine you want to have a `Map`, associating a name with a reference
7676
counted object. Typically, the map would be a cache of some sort. While the
7777
object exists, it should be referenced in the map. So we would like the Map

0 commit comments

Comments
 (0)