|
6 | 6 |
|
7 | 7 | Memory management is often a difficulty in defining an API. Should we let
|
8 | 8 | 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? |
10 | 10 |
|
11 | 11 | The latter approach is somewhat more costly in terms of efficiency (since
|
12 | 12 | 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. |
14 | 14 |
|
15 | 15 | Typically, such an approach is implemented using reference counting: all
|
16 | 16 | 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
|
71 | 71 | (one includes a reference to the other, and the other a reference to the
|
72 | 72 | first), their counter can never become 0, and thus they are never freed.
|
73 | 73 |
|
74 |
| -There are, however, common design patterns where this can severly interfer: |
| 74 | +There are, however, common design patterns where this can severly interfere: |
75 | 75 | imagine you want to have a `Map`, associating a name with a reference
|
76 | 76 | counted object. Typically, the map would be a cache of some sort. While the
|
77 | 77 | object exists, it should be referenced in the map. So we would like the Map
|
|
0 commit comments