3 ms·
Could you expand on this thought? I assumed that free() was invoked in the dealloc method, which was explicitly called if the release method reached a zero ref
by pohl 16y ago
Could you expand on this thought? I assumed that free() was invoked in the dealloc method, which was explicitly called if the release method reached a zero ref count.
- sil3ntmac 16y agoThat's correct, unless the object is autoreleased, in which case the system will get around to deallocating it after the current run loop iterates (provided you're using the default autorelease pool).
- DougBTX 16y agoWorth noting that an autoreleased object which you haven't retained will have a ref count of 1, so they are not an exception to the "freed when the ref count is zero" idea.
- pdhborges 16y agoYes, but if the object fall into the default autorelease pool you have no way to control when the memory is going to be released (at least without risking a segfault).
- pohl 16y agoThank you, that makes sense. So, if I understand this correctly: if one wanted to take advantage of an opportunity to do some cache-friendly reallocation, then avoiding autorelease pools would be necessary.
- microtherion 16y agoThat's rarely a realistic option if you use any Cocoa library code. autorelease is a pretty fundamental aspect of the Cocoa design.
- pohl 16y agoWouldn't it be more accurate to say that it's not a realistic option for objects that come from or depend on Cocoa library code? Or would the mere act of using cocoa in one part of my application somehow prevent me from exploiting such an opportunity in another part of my application? My instinct says that, for example, a plain C library that used such techniques would not cease to function just by being linked into a cocoa application.
- glhaynes 16y agoYour instinct is correct.
- microtherion 16y agoYes, you're right: If you create objects yourself and don't pass them through certain Cocoa library code, they will not be autoreleased. What I meant, however, is that most nontrivial Cocoa apps are likely to end up with a checkerboard allocation pattern, where the client allocated, controlled-lifetime objects are interspersed with Cocoa library allocated autoreleased objects with somewhat longer lifetimes, which may interfere to some extent with any strategy relying on controlling your object lifetime. Still, people can and do avoid autoreleasing objects if their lifetimes are well known in advance.