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