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 18:08:25 +0200
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