diff options
Diffstat (limited to 'docs/AutomaticReferenceCounting.html')
| -rw-r--r-- | docs/AutomaticReferenceCounting.html | 43 |
1 files changed, 41 insertions, 2 deletions
diff --git a/docs/AutomaticReferenceCounting.html b/docs/AutomaticReferenceCounting.html index 3f1ccaf..5354f8a 100644 --- a/docs/AutomaticReferenceCounting.html +++ b/docs/AutomaticReferenceCounting.html @@ -888,6 +888,15 @@ from non-ARC practice was acceptable because we had conservatively banned the synthesis in order to give ourselves exactly this leeway.</p></div> +<p>Applying <tt>__attribute__((NSObject))</tt> to a property not of +retainable object pointer type has the same behavior it does outside +of ARC: it requires the property type to be some sort of pointer and +permits the use of modifiers other than <tt>assign</tt>. These +modifiers only affect the synthesized getter and setter; direct +accesses to the ivar (even if synthesized) still have primitive +semantics, and the value in the ivar will not be automatically +released during deallocation.</p> + </div> <!-- ownership.spelling.property --> </div> <!-- ownership.spelling --> @@ -1602,6 +1611,36 @@ implementation must be very careful to do all the other work that <tt>NSObject</tt>'s <tt>dealloc</tt> would, which is outside the scope of this document to describe.</p></div> +<p>The instance variables for an ARC-compiled class will be destroyed +at some point after control enters the <tt>dealloc</tt> method for the +root class of the class. The ordering of the destruction of instance +variables is unspecified, both within a single class and between +subclasses and superclasses.</p> + +<div class="rationale"><p>Rationale: the traditional, non-ARC pattern +for destroying instance variables is to destroy them immediately +before calling <tt>[super dealloc]</tt>. Unfortunately, message +sends from the superclass are quite capable of reaching methods in the +subclass, and those methods may well read or write to those instance +variables. Making such message sends from dealloc is generally +discouraged, since the subclass may well rely on other invariants that +were broken during <tt>dealloc</tt>, but it's not so inescapably +dangerous that we felt comfortable calling it undefined behavior. +Therefore we chose to delay destroying the instance variables to a +point at which message sends are clearly disallowed: the point at +which the root class's deallocation routines take over.</p> + +<p>In most code, the difference is not observable. It can, however, +be observed if an instance variable holds a strong reference to an +object whose deallocation will trigger a side-effect which must be +carefully ordered with respect to the destruction of the super class. +Such code violates the design principle that semantically important +behavior should be explicit. A simple fix is to clear the instance +variable manually during <tt>dealloc</tt>; a more holistic solution is +to move semantically important side-effects out of +<tt>dealloc</tt> and into a separate teardown phase which can rely on +working with well-formed objects.</p></div> + </div> </div> <!-- misc.special_methods --> @@ -1865,9 +1904,9 @@ and <tt>cf_unknown_transfer</tt>.</p> <p>A pragma is provided to facilitate the mass annotation of interfaces:</p> -<pre>#pragma arc_cf_code_audited begin +<pre>#pragma clang arc_cf_code_audited begin ... -#pragma arc_cf_code_audited end</pre> +#pragma clang arc_cf_code_audited end</pre> <p>All C functions declared within the extent of this pragma are treated as if annotated with the <tt>cf_audited_transfer</tt> |
