Lines Matching refs:ARC
62 Objective-C Automatic Reference Counting (ARC)
83 The secondary purpose is to act as a rationale for why ARC was designed in this
184 ARC is under continual evolution, and this document must be updated as the
191 ARC applies to Objective-C pointer types, block pointer types, and
218 ARC may be explicitly enabled with the compiler flag ``-fobjc-arc``. It may
222 If ARC is enabled, ``__has_feature(objc_arc)`` will expand to 1 in the
232 the restrictions imposed on their use under ARC. Note in particular that it
247 ARC's semantics and restrictions.
251 We are not at liberty to require all code to be recompiled with ARC;
252 therefore, ARC must interoperate with Objective-C code which manages retains
295 to a class object. Otherwise ARC does not enforce the Objective-C type system
297 It is undefined behavior if ARC is exposed to an invalid pointer.
299 For ARC's purposes, a valid object is one with "well-behaved" retaining
347 In general, ARC does not perform retain or release operations when simply using
361 because the evaluations are unsequenced, and ARC simply exploits that here to
385 When passing such an argument, ARC retains the argument prior to making the
388 When receiving such an argument, ARC releases the argument at the end of the
440 When returning from such a function or method, ARC retains the value at the
443 When receiving a return result from such a function or method, ARC releases the
482 When returning from such a function or method, ARC retains the value at the
488 ARC performs no extra mandatory work on the caller side, although it may elect
493 It is common in non-ARC code to not return an autoreleased value; therefore
517 is ill-formed. There is no transfer of ownership, and ARC inserts no retain
521 pointer type. ARC retains the value, subject to the usual optimizations on
525 retainable object pointer type. ARC will release the value at the end of
529 These casts are required in order to transfer objects in and out of ARC
534 ARC to emit an unbalanced retain or release, respectively, is poor form.
559 transfers control into or out of ARC.
661 Consumed parameters are left out because ARC would naturally balance them
784 With the exception of ``weak``, these modifiers are available in non-ARC
804 Using ``strong`` by default is safe and consistent with the generic ARC rule
806 unfortunately, inconsistent with the non-ARC rule which states that such
808 untenable in ARC, since it leads to default-unsafe code. The main merit to
809 banning the properties is to avoid confusion with non-ARC practice, which did
813 from non-ARC practice was acceptable because we had conservatively banned the
817 pointer type has the same behavior it does outside of ARC: it requires the
935 filled with autoreleased objects, there is no way that ARC can provide any
993 initialization and deinitialization are under the control of ARC:
998 deinitialization are under the control of ARC
1000 initialization and deinitialization are under the control of ARC
1014 ARC must perform special operations when initializing an object and
1015 when destroying it. In many common situations, ARC knows when an
1017 operations are performed correctly. Otherwise, however, ARC requires
1019 because it is infeasible for ARC to dynamically infer whether they
1023 but ARC must perform one operation or the other. ARC chooses to always
1033 nontrivially-ownership-qualified type are not ABI-compatible with non-ARC
1034 code because the non-ARC code will consider the element type to be POD.
1035 Such arrays that are ``new[]``'d in ARC translation units cannot be
1036 ``delete[]``'d in non-ARC translation units and vice-versa.
1105 of the containing aggregate are unchanged from the semantics of an unqualified type in a non-ARC mo…
1305 or between ARC and non-ARC modes) under the following conditions:
1308 to the baseline, non-ARC rules (e.g. C struct compatibility or C++'s
1321 - one type must be unqualified (and thus declared in a non-ARC mode),
1327 registered with the Objective-C runtime. Non-ARC modes may still
1331 of non-trivial struct type to be written in ARC and called from
1332 non-ARC or vice-versa. The convention for this always transfers
1335 non-ARC callers must ensure that such fields are initialized to a +1
1336 reference, and non-ARC callees must balance that +1 by releasing the
1340 ARC and called from non-ARC or vice-versa. The convention for this
1360 - It permits ARC / non-ARC compatibility for structs containing only
1361 ``__strong`` references, as long as the non-ARC side is careful about
1369 ownership of that copy to the callee is generally better for ARC
1518 available outside of ARC, and may be tested for with the preprocessor query
1539 semantic intent, which is of use both to ARC (which, e.g., treats calls to
1600 * outside of ARC, the instance methods ``retain`` and ``autorelease``
1614 This is a new rule of the Objective-C language and applies outside of ARC.
1618 ARC's automatic code emission is more prone than most code to signature
1633 This specification describes ARC as performing specific ``retain`` and
1643 However, under certain circumstances, ARC is permitted to re-order and
1651 Specifically, ARC is sometimes permitted to optimize ``release``
1666 opaque to the optimizer, this is not possible, and so ARC's hands
1669 ARC makes no guarantees about the execution of a computation history
1670 which contains undefined behavior. In particular, ARC makes no
1673 ARC may assume that any retainable object pointers it receives or
1683 presence of race conditions. ARC does not have a stack-scanning
1688 ARC may assume that non-ARC code engages in sensible balancing
1692 and double-released, ARC may eliminate the inner retain and release;
1701 ARC may not allow a retainable object ``X`` to be deallocated at a
1753 example, given the code ``__strong id x = p->ivar;``, ARC must not
1773 ARC releases the original pointer. Note again, however, that
1774 dependence does not survive a store, so ARC does not guarantee the
1785 ARC must cause ``X`` to be deallocated by no later than the occurrence
1791 This rule is intended to prohibit ARC from observably extending the
1794 releases, this rule requires ARC to eliminate retains and release
1797 ARC's power to reorder the destruction of objects is critical to its
1809 In general, ARC maintains an invariant that a retainable object pointer held in
1862 ``retainCount`` is banned because ARC robs it of consistent semantics. The
1868 into an ARC program. At best, such code would do twice as much work as
1869 necessary; quite frequently, however, ARC and the explicit code would both
1875 While it *would* make it easier to develop code simultaneously for ARC and
1876 non-ARC, there is very little reason to do so except for certain library
1877 developers. ARC and non-ARC translation units share an execution model and
1879 faithfully maintains their code in non-ARC mode is suffering all the
1880 restrictions of ARC for zero benefit, while a developer who isn't testing the
1881 non-ARC mode is likely to be unpleasantly surprised if they try to go back to
1885 existing code to ARC. The best answer to that, given a number of other
1886 changes and restrictions in ARC, is to provide a specialized tool to assist
1890 semantics of ARC; many tricks which worked tolerably under manual reference
1891 counting will misbehave if ARC performs an ephemeral extra retain or two. If
1892 absolutely required, it is still possible to implement them in non-ARC code,
1916 Even though ARC destroys instance variables automatically, there are still
1924 implementation outside of ARC. Such an implementation must be very careful
1928 The instance variables for an ARC-compiled class will be destroyed at some
1935 The traditional, non-ARC pattern for destroying instance variables is to
1971 ``@autoreleasepool`` may be used in non-ARC translation units, with equivalent
2104 ``__block`` variables, which is a shift in semantics from non-ARC, where
2127 By default in Objective C, ARC is not exception-safe for normal releases:
2144 ARC-generated code leaks by default on exceptions, which is just fine if the
2152 C++ already introduces pervasive exceptions-cleanup code of the sort that ARC
2156 ARC does end the lifetimes of ``__weak`` objects when an exception terminates
2187 some classes offer their users direct access for efficiency. If ARC is not
2189 cause the owning object to be reclaimed too soon. This attribute informs ARC
2212 this requires a very explicit annotation, which allows ARC to trust the user
2226 ARC does not manage pointers of CoreFoundation type (or any of the related
2228 retain/release operation). In fact, ARC does not even know how to
2284 A significant inconvenience in ARC programming is the necessity of
2288 the static analyzer and ARC. The single-file restriction on the pragma is
2297 This section describes the interaction between the ARC runtime and the code
2298 generated by the ARC compiler. This is not part of the ARC language
2323 * it is much easier to recognize the C functions in the ARC optimizer, and