Re: When init returns nil does it cause a leak
I did talk to an Apple engineer about this and when I argued for
[super dealloc] I was told that it would be fine.
I then logged a radar against the seemingly incorrect documentation, I
got a reply stating that [self release] is the recommended approach by
the AppKit team.
My radar was closed on 24-Feb-2009, so I think this is the most
current recommendation.
Jesper
On May 19, 2009, at 3:01 PM, Nathan Vander Wilt wrote:
On May 19, 2009, at 9:37 AM, Jean-Daniel Dupas wrote:
Le 19 mai 09 à 18:24, Reza Farhad a écrit :
Hi all
we have an object that gets initialized like most other objects
-(id)init
{
self = [ super init ];
if ( self ){
...do something;
}
return self;
}
if [ super init ] returns nil does this cause a leak, as the
memory has already been created by calling alloc when trying to
create the object
AnObject*object = [[ AnObject alloc ] init ];
I am sure the answer is simple but this suddenly stumbled me.
Thanks
The answer is in the Cocoa Fundamentals Guide > Cocoa Objects >
Object Creation > Implementing Initializer
with a lots of other useful info.
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html
There was a thread in ObjC-language about this a while back:
http://lists.apple.com/archives/ObjC-Language/2008/Sep/msg00132.html
In the followup, an Apple runtime engineer recommends calling [super
dealloc] before returning nil, saying "[self dealloc] or [self
release] are bad because they might call some subclass's -dealloc
method even though the subclass's -init hasn't done anything yet."
Of course, in practice [self release] should usually work just fine as
well, and avoids breaking the "never call dealloc except in -dealloc"
taboo. And indeed, this is what the documentation and sample code do
as well. I think you would be reasonably justified to do either. I'm
still debating this myself for our company's code, but the fact is
that they both work in most situations.
hope this helps,
-natevw
___
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/jsbache%40adobe.com
This email sent to jsba...@adobe.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
Re: When init returns nil does it cause a leak
On May 19, 2009, at 9:37 AM, Jean-Daniel Dupas wrote:
Le 19 mai 09 à 18:24, Reza Farhad a écrit :
Hi all
we have an object that gets initialized like most other objects
-(id)init
{
self = [ super init ];
if ( self ){
...do something;
}
return self;
}
if [ super init ] returns nil does this cause a leak, as the
memory has already been created by calling alloc when trying to
create the object
AnObject*object = [[ AnObject alloc ] init ];
I am sure the answer is simple but this suddenly stumbled me.
Thanks
The answer is in the Cocoa Fundamentals Guide > Cocoa Objects >
Object Creation > Implementing Initializer
with a lots of other useful info.
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html
There was a thread in ObjC-language about this a while back:
http://lists.apple.com/archives/ObjC-Language/2008/Sep/msg00132.html
In the followup, an Apple runtime engineer recommends calling [super
dealloc] before returning nil, saying "[self dealloc] or [self
release] are bad because they might call some subclass's -dealloc
method even though the subclass's -init hasn't done anything yet."
Of course, in practice [self release] should usually work just fine as
well, and avoids breaking the "never call dealloc except in -dealloc"
taboo. And indeed, this is what the documentation and sample code do
as well. I think you would be reasonably justified to do either. I'm
still debating this myself for our company's code, but the fact is
that they both work in most situations.
hope this helps,
-natevw
___
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
Re: When init returns nil does it cause a leak
On Tue, May 19, 2009 at 2:24 PM, Gwynne Raskind wrote: > On May 19, 2009, at 2:15 PM, Jesper Storm Bache wrote: >> >> In the obj-c world we then have to implement classes to be able to handle >> a dealloc call before the initializer has completely executed. > > My 2 cents... > > If we aren't implementing our classes this way to begin with, then we're not > programming our Objective-C correctly at all. As far as I'm concerned, > "dealloc should be able to handle a partially initialized object" should be > a language requirement. If any of Apple's classes don't handle this case > properly, then it's a bug that should be filed. Since your instance variables are guaranteed to be zero-filled as soon as the object is allocated, even before initialization, writing your dealloc method to correctly handle an uninitialized object should be trivial. Most dealloc methods will work with zero modification, and where changes are needed, they tend to be useful belt-and-suspenders checks anyway. Mike ___ 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
Re: When init returns nil does it cause a leak
On May 19, 2009, at 2:15 PM, Jesper Storm Bache wrote: In the obj-c world we then have to implement classes to be able to handle a dealloc call before the initializer has completely executed. My 2 cents... If we aren't implementing our classes this way to begin with, then we're not programming our Objective-C correctly at all. As far as I'm concerned, "dealloc should be able to handle a partially initialized object" should be a language requirement. If any of Apple's classes don't handle this case properly, then it's a bug that should be filed. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable." ___ 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
Re: When init returns nil does it cause a leak
On May 19, 2009, at 10:58 AM, Quincey Morris wrote: On May 19, 2009, at 09:32, Jesper Storm Bache wrote: I personally disagree with the Apple recommendation, and I vote for calling [super dealloc] when initialization fails - because this will invoke dealloc only in the base classes where init succeeded. First of all, in general, it can't work. If it were permissible to write '[super dealloc]' anywhere other than in a dealloc method, you'd have to be certain that there were no outstanding extra retains on the object, and you can't know that. One of the "base" inits might have done something that resulted in a retain/autorelease on the object, for example. Interesting & a valid point. Such a use case definitely does *not* work with an explicit dealloc mechanism. Second, in general, when an init method decides to fail, its object is already partially initialized. So in addition to (hypothetically) calling '[super dealloc]', it would also have to back out some initializations, and it comes down to a choice between (a) adding code to init to back out the initializations or (b) adding code to dealloc to avoid doing anything dangerous on a partially-initialized object. That is right. The issue I have with release is if you have a class hierarchy of three classes A<-B<-C and B fails, then you will get a dealloc call in C before C's init returned from [super init]. By calling dealloc on the super class you get C++ style behavior, where you only get destructor calls in instances where the init call succeeded. It is correct that this require implementing init in a way that provide proper clean up if a failure should occur. The benefit we get from obj-c, is that we know that all ivars are set to 0, so we do get some kind of class hierarchy wide initialization before our initializers run. If you use the [self release] method, then your canonical no-value must be 0 for all of your data types. I can't find any documentation stating that retain/autorelease in initializers is bad, so following the Apple guide lines is the right way to go. In the obj-c world we then have to implement classes to be able to handle a dealloc call before the initializer has completely executed. Thanks for your comments. Jesper The problem with (a) is that it will duplicate -- multiple times if there are multiple errors to detect -- some code that's already in dealloc. The advantage of (b) is that it centralizes the knowledge of how to handle un-initialization in dealloc. (In most cases, the only backing out that needs to be done is releasing instance variables. As far as that's concerned, [self dealloc] is safe without special-casing anything.) ___ 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/jsbache%40adobe.com This email sent to jsba...@adobe.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
Re: When init returns nil does it cause a leak
On May 19, 2009, at 09:32, Jesper Storm Bache wrote: I personally disagree with the Apple recommendation, and I vote for calling [super dealloc] when initialization fails - because this will invoke dealloc only in the base classes where init succeeded. First of all, in general, it can't work. If it were permissible to write '[super dealloc]' anywhere other than in a dealloc method, you'd have to be certain that there were no outstanding extra retains on the object, and you can't know that. One of the "base" inits might have done something that resulted in a retain/autorelease on the object, for example. Second, in general, when an init method decides to fail, its object is already partially initialized. So in addition to (hypothetically) calling '[super dealloc]', it would also have to back out some initializations, and it comes down to a choice between (a) adding code to init to back out the initializations or (b) adding code to dealloc to avoid doing anything dangerous on a partially-initialized object. The problem with (a) is that it will duplicate -- multiple times if there are multiple errors to detect -- some code that's already in dealloc. The advantage of (b) is that it centralizes the knowledge of how to handle un-initialization in dealloc. (In most cases, the only backing out that needs to be done is releasing instance variables. As far as that's concerned, [self dealloc] is safe without special-casing anything.) ___ 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
Re: When init returns nil does it cause a leak
Le 19 mai 09 à 18:24, Reza Farhad a écrit :
Hi all
we have an object that gets initialized like most other objects
-(id)init
{
self = [ super init ];
if ( self ){
...do something;
}
return self;
}
if [ super init ] returns nil does this cause a leak, as the memory
has already been created by calling alloc when trying to create the
object
AnObject*object = [[ AnObject alloc ] init ];
I am sure the answer is simple but this suddenly stumbled me.
Thanks
The answer is in the Cocoa Fundamentals Guide > Cocoa Objects > Object
Creation > Implementing Initializer
with a lots of other useful info.
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html
___
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
Re: When init returns nil does it cause a leak
Apple's take on this is that when an initializer fails, then it should
call release on itself and return nil.
See: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html#/
/apple_ref/doc/uid/TP30001163-CH22-SW13
This means that if super returns nil, then your memory should already
be deallocated.
I personally disagree with the Apple recommendation, and I vote for
calling [super dealloc] when initialization fails - because this will
invoke dealloc only in the base classes where init succeeded.
In any case, when nil is returned, you should expect that your storage
may already have been deleted.
Jesper Storm Bache
On May 19, 2009, at 9:24 AM, Reza Farhad wrote:
Hi all
we have an object that gets initialized like most other objects
-(id)init
{
self = [ super init ];
if ( self ){
...do something;
}
return self;
}
if [ super init ] returns nil does this cause a leak, as the memory
has already been created by calling alloc when trying to create the
object
AnObject*object = [[ AnObject alloc ] init ];
I am sure the answer is simple but this suddenly stumbled me.
Thanks
Reza
___
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/jsbache%40adobe.com
This email sent to jsba...@adobe.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
When init returns nil does it cause a leak
Hi all
we have an object that gets initialized like most other objects
-(id)init
{
self = [ super init ];
if ( self ){
...do something;
}
return self;
}
if [ super init ] returns nil does this cause a leak, as the memory
has already been created by calling alloc when trying to create the
object
AnObject*object = [[ AnObject alloc ] init ];
I am sure the answer is simple but this suddenly stumbled me.
Thanks
Reza
___
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
