2 ms·
That just lets it release earlier, not retain/release less often. ARC can't do anything magic here vs. something like really careful use of std::move & const r
by kllrnohj 8y ago
That just lets it release earlier, not retain/release less often.
ARC can't do anything magic here vs. something like really careful use of std::move & const references.
- favorited 8y agoARC optimizations do let it retain/release less often. For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.
- kllrnohj 8y ago> For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely. Are you just referring to standard RVO? If you return a std::shared_ptr in C++ today you won't get the equivalent of retain+release, either, RVO avoids that.
- vlovich123 7y agoDid you even take a look at the doc I posted? > For example, if the user puts logging statements in retain, they should not be surprised if those statements are executed more or less often depending on optimization settings > In general, ARC does not perform retain or release operations when simply using a retainable object pointer as an operand within an expression > However, C and C++ already call this undefined behavior because the evaluations are unsequenced, and ARC simply exploits that here to avoid needing to retain arguments across a large number of calls. > ARC performs no extra mandatory work on the caller side, although it may elect to do something to shorten the lifetime of the returned value.