Re: Memory management on returning nil in init
Re: Memory management on returning nil in init
- Subject: Re: Memory management on returning nil in init
- From: Eiko Bleicher <email@hidden>
- Date: Mon, 21 Jun 2010 19:00:23 +0200
If the boolean value is distracting, here it is without:
-(id) init
{
if (self = [super init])
{
BOOL noValidObject = doSomeMagicConditionalChecking();
if (noValidObject) {
[self release];
[return nil];
}
// Normal initialization here
}
return self;
}
It seems to me you suggest that I could use
-(id) init
{
BOOL noValidObject = doSomeMagicConditionalChecking();
if (noValidObject) return nil;
if (self = [super init])
{
// Normal initialization here
}
return self;
}
instead. But my point is that *this* code would actually leak, because the object has already been alloc'ed and is not released.
Eiko
Am 21.06.2010 um 18:41 schrieb Phil Hystad:
> I do not understand your argument -- apparently the ok variable is input to this initWithBool method and this method DOES NOT alter the ok variable in any way. Therefore, when you test the ok variable, you are testing a condition that is totally independent of anything that initWithBool might do. But, you seem to be using it as a condition test that might be confused with the result of the [super init] message. Thus, either this is a bug in your code in how the ok variable is being used or you are doing something else that defies understanding from the code fragment we have before us -- thus, my original question. My question was not about how Obj-c works with memory management and when to properly do a release, that was another subject that was correctly answered by several others.
>
>
> On Jun 21, 2010, at 9:08 AM, Eiko Bleicher wrote:
>
>> That would leak. Shouldn't this instance be released? Alloc already did its job if we get into init. On the other hand, we shouldn't call release, because super wasn't initialized. So as of my (maybe limited) understanding by now, doing the code after [super init] is the way to go.
>>
>>
>> Am 21.06.2010 um 18:00 schrieb Phil Hystad:
>>
>>> Does this mean we don't get to find out what the ok variable is all about? If the ok variable has meaning then the code would be much better written as something like:
>>>
>>> -(id) initWithBool:(BOOL)ok
>>> {
>>> if ( !ok ) return nil;
>>> ...rest of code...
>>> }
>>>
>>>
>>>
>>> On Jun 21, 2010, at 7:55 AM, Eiko Bleicher wrote:
>>>
>>>> Thank you all, this gives me confidence in my code.
>>>>
>>>> I was just hesistant because I didn't call alloc in the initializer - but that's probably one of the reasons why you always use alloc/init together when calling. :-)
>>>>
>>>> Thanks to everyone who responded.
>>>> Eiko
>>>>
>>>>
>>>> Am 21.06.2010 um 16:51 schrieb Markus Hanauska:
>>>>
>>>>>
>>>>> On Monday, 2010-06-21, at 16:43, Eiko Bleicher wrote:
>>>>>
>>>>>> -(id) initWithBool:(BOOL)ok
>>>>>> {
>>>>>> if (self = [super init])
>>>>>> {
>>>>>> if (!ok) {
>>>>>> return nil; // Point of interest
>>>>>> }
>>>>>> }
>>>>>> return self;
>>>>>> }
>>>>>>
>>>>>> Does this code leak?
>>>>>
>>>>> According to my understanding of Cocoa, it does leak. You should call [self release], as otherwise the just created object (the object has already been created by [CLASS alloc] when init is being called) is never released otherwise. Further no other object that [super init] might create is released. My inits usually look like this:
>>>>>
>>>>> - (id)initWithBool:(BOOL)ok
>>>>> {
>>>>> self = [super init];
>>>>> if (self) {
>>>>> if (!ok) {
>>>>> [self release];
>>>>> self = nil;
>>>>> }
>>>>> }
>>>>> return self;
>>>>> }
>>>>>
>>>>> --
>>>>> Markus Hanauska
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> 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