Re: menu madness with retain count
Re: menu madness with retain count
- Subject: Re: menu madness with retain count
- From: "Gary L. Wade" <email@hidden>
- Date: Tue, 27 Apr 2010 14:22:43 -0700
- Thread-topic: menu madness with retain count
On 04/27/2010 2:12 PM, "Bill Bumgarner" <email@hidden> wrote:
>
> On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:
>
>> On 04/27/2010 1:58 PM, "Bill Bumgarner" <email@hidden> wrote:
>>
>>> Frankly, the -retainCount method should be deprecated and, eventually,
>>> removed.
>>
>> I wouldn't go THAT far; after all, when you're tracking a memory leak,
>> checking your influence on the retain count is important to your
>> investigation. Hopefully that's why the original poster is looking at it.
>
> The combination of leaks, zombies, heap, and malloc stack logging are much
> *much* more powerful and effective than trying to debug a leak, over-retain or
> under-retain with -retainCount.
>
> b.bum
>
Yes, but how would you use those to determine why an Apple framework now
chooses to retain a delegate (I'm referring to one particular one I
discovered), thereby causing a retain cycle? It's not a memory leak in the
sense that Instruments or leaks would ever catch it. Calling -retainCount
immediately before and after the -setDelegate call is pretty much the only
way.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden