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
984 ARC cannot differentiate between an assignment operator which is intended to
986 a value. Therefore the object's pointer must be valid before letting ARC at
996 non-ARC code because the element type is non-POD: such arrays that are
997 ``new[]``'d in ARC translation units cannot be ``delete[]``'d in non-ARC
1079 Definition Rule to use a class outside of ARC that, under ARC, would have a
1084 Unlike in C, we can express all the necessary ARC semantics for
1089 outside of ARC, objects of the type will be passed and returned in an
1230 available outside of ARC, and may be tested for with the preprocessor query
1251 semantic intent, which is of use both to ARC (which, e.g., treats calls to
1312 * outside of ARC, the instance methods ``retain`` and ``autorelease``
1326 This is a new rule of the Objective-C language and applies outside of ARC.
1330 ARC's automatic code emission is more prone than most code to signature
1345 This specification describes ARC as performing specific ``retain`` and
1355 However, under certain circumstances, ARC is permitted to re-order and
1363 Specifically, ARC is sometimes permitted to optimize ``release``
1378 opaque to the optimizer, this is not possible, and so ARC's hands
1381 ARC makes no guarantees about the execution of a computation history
1382 which contains undefined behavior. In particular, ARC makes no
1385 ARC may assume that any retainable object pointers it receives or
1395 presence of race conditions. ARC does not have a stack-scanning
1400 ARC may assume that non-ARC code engages in sensible balancing
1404 and double-released, ARC may eliminate the inner retain and release;
1413 ARC may not allow a retainable object ``X`` to be deallocated at a
1465 example, given the code ``__strong id x = p->ivar;``, ARC must not
1485 ARC releases the original pointer. Note again, however, that
1486 dependence does not survive a store, so ARC does not guarantee the
1497 ARC must cause ``X`` to be deallocated by no later than the occurrence
1503 This rule is intended to prohibit ARC from observably extending the
1506 releases, this rule requires ARC to eliminate retains and release
1509 ARC's power to reorder the destruction of objects is critical to its
1521 In general, ARC maintains an invariant that a retainable object pointer held in
1574 ``retainCount`` is banned because ARC robs it of consistent semantics. The
1580 into an ARC program. At best, such code would do twice as much work as
1581 necessary; quite frequently, however, ARC and the explicit code would both
1587 While it *would* make it easier to develop code simultaneously for ARC and
1588 non-ARC, there is very little reason to do so except for certain library
1589 developers. ARC and non-ARC translation units share an execution model and
1591 faithfully maintains their code in non-ARC mode is suffering all the
1592 restrictions of ARC for zero benefit, while a developer who isn't testing the
1593 non-ARC mode is likely to be unpleasantly surprised if they try to go back to
1597 existing code to ARC. The best answer to that, given a number of other
1598 changes and restrictions in ARC, is to provide a specialized tool to assist
1602 semantics of ARC; many tricks which worked tolerably under manual reference
1603 counting will misbehave if ARC performs an ephemeral extra retain or two. If
1604 absolutely required, it is still possible to implement them in non-ARC code,
1628 Even though ARC destroys instance variables automatically, there are still
1636 implementation outside of ARC. Such an implementation must be very careful
1640 The instance variables for an ARC-compiled class will be destroyed at some
1647 The traditional, non-ARC pattern for destroying instance variables is to
1683 ``@autoreleasepool`` may be used in non-ARC translation units, with equivalent
1757 ``__block`` variables, which is a shift in semantics from non-ARC, where
1774 By default in Objective C, ARC is not exception-safe for normal releases:
1791 ARC-generated code leaks by default on exceptions, which is just fine if the
1799 C++ already introduces pervasive exceptions-cleanup code of the sort that ARC
1803 ARC does end the lifetimes of ``__weak`` objects when an exception terminates
1834 some classes offer their users direct access for efficiency. If ARC is not
1836 cause the owning object to be reclaimed too soon. This attribute informs ARC
1859 this requires a very explicit annotation, which allows ARC to trust the user
1873 ARC does not manage pointers of CoreFoundation type (or any of the related
1875 retain/release operation). In fact, ARC does not even know how to
1931 A significant inconvenience in ARC programming is the necessity of
1935 the static analyzer and ARC. The single-file restriction on the pragma is
1944 This section describes the interaction between the ARC runtime and the code
1945 generated by the ARC compiler. This is not part of the ARC language
1970 * it is much easier to recognize the C functions in the ARC optimizer, and