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 (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
