Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>ARC guarantees that objects will be automatically reference counted at compile time. It goes further and places the requirement that the code be algorithmically fully coherent (which manifests as errors when trying to convert between, say, <code>void*</code> and <code>id</code> via casting -- under ARC, you have to qualify the memory management policy across such casts).</p> <p>ARC is not a garbage collector; there is no scanning, no threading, and no stop-the-world behavior. This means more predictable behavior at the cost of things like automatic cycle detection.</p> <p>While ARC guarantees that an object's lifespan will be automatically managed, ARC does not guarantee that lifespan beyond "the object will live for at least as long, maybe longer, than it is used in the code".</p> <p>In fact, you might see lifespan changes depending on both the optimization level of the code and whether or not the factory method you invoked is compiled in an ARC vs. manual-retain-release [MRR] source file. And the lifespan may change across releases of the compiler and/or runtime.</p> <p>For example, ARC code calling into a factory method can sometimes short-circuit the <code>autorelease</code> entirely.</p> <p>Sounds scary, but it isn't because of the algorithmic coherence requirement. Since there cannot be ambiguous behavior (as there can in plain old MRR), that the lifespan might change over releases <em>should not</em> impact your code.</p> <p>Of course, this means that you <strong>should not</strong> have order dependencies between <code>dealloc</code> methods. This should not be an onerous requirement as having order dependencies between <code>dealloc</code> methods under MRR was always a nasty thing.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload