• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ARC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ARC


  • Subject: Re: ARC
  • From: Jean-Daniel via Cocoa-dev <email@hidden>
  • Date: Mon, 26 Aug 2019 21:43:32 +0400

A better way to investigate such issue is using the memory debugging tools in
Instrument IMHO.
That would let you see all stack traces of retain/release calls.

> Le 26 août 2019 à 04:14, Turtle Creek Software via Cocoa-dev
> <email@hidden> a écrit :
>
> In GSAppDelegate.h
>  GSOutlineWindowController *mainWindowController;
>
> In GSAppDelegate.mm
> - (void) showOutlineWindow
> {
>     if (mainWindowController == NULL)
>          mainWindowController = [[GSOutlineWindowController alloc]
> initWithWindowNibName : @"GSOutlineWindowController"];
>     [mainWindowController showWindow : self];
> }
>
> We don't do any ref-counting at all.  A search for CFRetain and CFRelease
> showed zero items.
>
> I would say that ARC is certainly way better than the previous manual
> ref-counting.  That must have been hellish.
> Fortunately we only started the Carbon->Cocoa port 3 years ago, so we
> didn't need to retain/release.
> But we have wasted at least a month, tracking down mysterious object
> deletions that theoretically should not happen.
>
> At this point we pretty much have breakpoints on dealloc() for every
> class.  That lets us know when something is
> dying, but gives no clue as to why.  Breakpoints on release() go deep into
> Apple Assembly code.
>
> On Sun, Aug 25, 2019 at 12:42 PM Jens Alfke <email@hidden> wrote:
>
>>
>>> On Aug 24, 2019, at 4:46 AM, Turtle Creek Software <
>> email@hidden> wrote:
>>>
>>> Our app delegate class is not deallocated.  The window controller is
>> deallocated
>>> despite the member reference there.
>>
>> That should not be possible. Could you paste the exact line of code that
>> declares the window-controller reference in the app delegate?
>>
>> Have you verified that, at the point when the controller is dealloced, the
>> reference in the app delegate is still non-nil? (I sometimes find it useful
>> to set a breakpoint in the dealloc method, in weird cases like this.)
>>
>> Do you have any remaining code that messes with ref-counting, I.e. by
>> using CFRetain/Release on Obj-C objects?
>>
>> —Jens
>>
>> (And let me chime in that ARC is an excellent feature. Cocoa used to have
>> ‘true’ garbage collection as an option, but it was rarely used on Mac due
>> to memory and performance impact, and never implemented on iOS for that
>> reason. ARC works much better. Swift memory management is based on ARC, so
>> it’s definitely the way of the future.)
>>
> _______________________________________________
>
> 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

_______________________________________________

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

  • Follow-Ups:
    • Re: ARC
      • From: Turtle Creek Software via Cocoa-dev <email@hidden>
References: 
 >Re: ARC (From: Turtle Creek Software via Cocoa-dev <email@hidden>)
 >Re: ARC (From: Jens Alfke via Cocoa-dev <email@hidden>)
 >Re: ARC (From: Turtle Creek Software via Cocoa-dev <email@hidden>)

  • Prev by Date: Re: Cocoa-dev Digest, Vol 16, Issue 72
  • Next by Date: Re: ARC
  • Previous by thread: Re: ARC
  • Next by thread: Re: ARC
  • Index(es):
    • Date
    • Thread