[cfe-dev] NSAutoreleasePool checker
Ted Kremenek
kremenek at apple.com
Fri May 27 13:28:44 PDT 2011
Is there a
On May 27, 2011, at 1:16 PM, David Chisnall wrote:
> On 27 May 2011, at 20:47, Ted Kremenek wrote:
>
>> On May 27, 2011, at 12:28 PM, Sean McBride wrote:
>>
>>>> Does anyone object if I enable it unconditionally?
>>>> Sending -drain instead of -release to autorelease pools works in both GC
>>>> and non-GC mode, while sending -release is a no-op in GC mode, so it's
>>>> good style to use -drain always (recent Apple examples use -drain even
>>>> in non-GC mode).
>>>
>>> And drain works back to 10.4 even. Personally, I'd like to see this change.
>>
>> I think it is fine to worth considering this change because it "makes sense for all users." If this is in the recommended Cocoa API practices, for example, I'd be more than happy to make this change. If this makes sense for (say) all GNUStep users, and we can determine that we are using GNUStep, then I'd be fine with turning it on in that case as well because that would make sense for that platform (as decided by those project owners).
>
> This has been the recommended practice for Cocoa since 10.5.
If you can find a documentation reference that clearly states that, then I'm happy to make the switch. All I see is:
> Garbage Collection
> In a garbage-collected environment, there is no need for autorelease pools. You may, however, write a framework that is designed to work in both a garbage-collected and reference-counted environment. In this case, you can use autorelease pools to hint to the collector that collection may be appropriate. In a garbage-collected environment, sending a drain message to a pool triggers garbage collection if necessary; release, however, is a no-op. In a reference-counted environment, drain has the same effect as release. Typically, therefore, you should use draininstead of release.
which is not the same thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110527/d9850d5a/attachment.html>
More information about the cfe-dev
mailing list