Re: static analyzers says I'm leaking, I _think_ I'm not
Re: static analyzers says I'm leaking, I _think_ I'm not
- Subject: Re: static analyzers says I'm leaking, I _think_ I'm not
- From: Aaron Montgomery <email@hidden>
- Date: Wed, 06 May 2015 14:40:32 -0700
If the property is set to "retain", then the line
self.cycler = [[[….initWithGrid:self] autorelease]
will cause the setter to retain the passed in object, so after this line, _cycler will have a (heuristic) retain count of 2 (an alloc and a retain).
After this, when the autorelease pool is drained, reducing the (heuristic) retain count by 1: you've still got a hold of it in the property.
Then in dealloc, you release the object in dealloc to reduce the (heuristic) retain count to 0.
To release the object, you can use
[_cycler release];
or
self.cycler = nil;
or you may be able to not even bother if you won't create a cycle, I haven't done manual memory in a while, but I think retained properties are released at destruction automatically.
Aaron
> On May 6, 2015, at 2:30 PM, Michael David Crawford <email@hidden> wrote:
>
> Am I correct that autoreleased objects are released after each round
> of even processing?
>
> In this case my cycler needs to hang around for the life of the whole program.
>
> Thanks,
>
> Mike
> Michael David Crawford, Consulting Software Engineer
> email@hidden
> http://www.warplife.com/mdc/
>
> Available for Software Development in the Portland, Oregon Metropolitan
> Area.
>
>
> On Wed, May 6, 2015 at 2:25 PM, Aaron Montgomery
> <email@hidden> wrote:
>> Having cycler set to "assign" and then releasing it in dealloc doesn't feel right. Why not set cycler to "retain", add an autorelease in init then release _cycler in dealloc?
>>
>> Aaron
>>
>>
>>> On May 6, 2015, at 1:57 PM, Michael David Crawford <email@hidden> wrote:
>>>
>>> I've had problems in the past where I failed to understand the Cocoa
>>> ownership conventions, I'm willing to grant that could be the case.
>>>
>>> I know for sure that the analyzer enforces the naming conventions,
>>> that is, the exact same function names in C or C++ won't yield that
>>> same warnings as "alloc", "new" or "copy" would in Objective-C.
>>>
>>> I'm reluctant to use ARC because in my honest opinion, ARC will get
>>> the leaks and most out of the crashes out of skanky code. If you
>>> don't use ARC, you get them out by fixing the skank:
>>>
>>> "Dave, why do you add twelve extra bytes to all of Spellswell's allocations?"
>>>
>>> "That was so Spellswell would stop crashing." Facepalm.
>>>
>>> // LifeGrid.h
>>> @property (assign, nonatomic) GridCycler *cycler;
>>>
>>> // Lifegrid.m - init
>>> self.cycler = [[GridCycler alloc] initWithGrid: self]; // Potential
>>> leak of an object
>>> if ( nil == self.cycler ) goto cycler_failed;
>>>
>>> // dealloc
>>> [self.cycler release];
>>>
>>> Expanding the "potential leak" message yields:
>>>
>>> 1. assuming 'self' is not nil
>>>
>>> 2. method returns Objective-C object with +1 retain count
>>>
>>> 3. Object leaked: allocated object is not references later in this
>>> execution path and has a retain count of +1.
>>>
>>> Isn't that what I want? I should be taking ownership of it with
>>> "alloc/initWithGrid".
>>>
>>> (initWithGrid doesn't do a cyclic retain.)
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>> Michael David Crawford, Consulting Software Engineer
>>> email@hidden
>>> http://www.warplife.com/mdc/
>>>
>>> Available for Software Development in the Portland, Oregon Metropolitan
>>> Area.
>>> _______________________________________________
>>>
>>> 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