Re: Analyser reports memory leak… where?
Re: Analyser reports memory leak… where?
- Subject: Re: Analyser reports memory leak… where?
- From: Bill Cheeseman <email@hidden>
- Date: Thu, 12 Sep 2013 11:00:24 -0400
On Sep 12, 2013, at 9:16 AM, Roland King <email@hidden> wrote:
> setEventTypes: takes a parameter and returns nothing. What it does with that parameter is entirely up to it, it may retain it if it wishes to be released later, or do any other thing it wants. If the analyser doesn't much like what setEventTypes: is doing, it would complain about setEventTypes:, which it's not doing, it's complaining about a caller. That method doesn't return anything and has no special naming so the analyser will presume it correctly to do nothing net-net to its argument.
>
> -eventTypes doesn't need the new or copy because it does not return an object owned by the caller. Whether the object it returns is already owned by itself to be released later is irrelevant, the refcount has not been increased before return to the caller so the method is correctly named and the analyser can properly assume it to be a +0 method. And apart from that it's not even called in the piece of code in question so that's not really relevant.
I don't follow you. -setEventTypes: is properly named and properly written. It is (except for the last statement) standard setter code. One would not expect an error here. It increases the refcount of the newly created object passed in the parameter and assigned to the iVar by calling -retain on it. The object that is released in -setEventTypes: is a different object, the old iVar. For code that refers to an iVar without regard to what object is assigned to it, you are correct that the net effect on the iVar's refcount is 0. This is a great convenience for most code. But for unusual code like the example given, where a new object is being created to replace the object currently assigned to iVar, care must be taken to distinguish between the different objects.
-eventTypes creates the new object with a refcount of 1 by calling -newEventTypes, and then it increments its refcount by 1 by calling -setEventTypes:. The new object now has a refcount of 2. The release of the new object at the end of -eventTypes drops it back to 1. That is 1 more than it was before -eventTypes was called, because the new object didn't exist before -eventTypes was called.
-eventTypes: is, in fact, a classic "new" method, though a bit oddly written. All in the one method (by calls to utility methods), it creates a new object with a refcount of 1 by calling +alloc indirectly, increases its refcount by 1 more by calling -setEventTypes:, decreases its refcount by 1 to balance the second increase, and returns it with a refcount of 1 without autoreleasing it. It does own the new object, and the method should have "new" in its name.
The fact that -setEventTypes: releases the old object that was formerly held by the iVar isn't relevant to the Analyzer. It's the new object created in -eventTypes by the call to -newEventTypes that the Analyzer cares about. It is doing nothing more nor less than enforcing a naming convention. Fix the name and the Analyzer is happy. No need to change the code, because the code is correct.
--
Bill Cheeseman - 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