I agree that it's inappropriate to expect that the analyzer will
assume that the getters and setters work the way they conventionally
do. One reason we have properties is so that, when required, they can
do other things:
- (void) setAdversary: (int)enemy
{
_enemy = enemy;
[_enemy setUpTheBomb];
}
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Wed, May 6, 2015 at 2:54 PM, Ken Thomases <k...@codeweavers.com> wrote:
> On May 6, 2015, at 4:40 PM, Aaron Montgomery <eey...@monsterworks.com> wrote:
>
>> 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.
>
> Or, in other words, sending an object -autorelease is just like sending it a
> -release only the effect is delayed.
>
> A combined alloc/init/autorelease balances itself. A strong (or "retain")
> property will be balanced if the setter is written properly (which a
> synthesized setter will be) and you release in -dealloc.
>
>> To release the object, you can use
>>
>> [_cycler release];
>>
>> or
>>
>> self.cycler = nil;
>
> Better to use the former in case the setter (in this class or a subclass)
> does extra work that wouldn't be appropriate during deallocation.
>
>> 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.
>
> No, in manual retain-release, nothing is released automatically. In
> -dealloc, you have to explicitly release the objects you own.
>
> Regards,
> Ken
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
