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 (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:
>> http://lists.apple.com/mailman/options/cocoa-dev/phystad%40mac.com
>>
>> This email sent to phys...@mac.com
>
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
