Re: alloc, init and autorelease/release
Re: alloc, init and autorelease/release
- Subject: Re: alloc, init and autorelease/release
- From: Felix Schwarz <email@hidden>
- Date: Mon, 24 Oct 2005 16:07:32 +0200
Thanks for the answers!
FYI, what I'm trying to do here is to return a nil pointer in case
something in the init-method failed (i.e. allocation of additional
buffer memory failed or not all paramters were supplied).
Regarding [self autorelease], I just want to be sure there isn't even
the slightiest chance that any storage that might still be required,
is free()d up while a routine of the object whose storage is being
free()d does still execute anything.
Best regards,
Felix
Am 23.10.2005 um 12:47 schrieb jkp:
I think he is trying to work out if you can do clever things in
your init methods like return an existing instance for example
(like with a singleton class, or some caching scheme). The
examples he gave show ways you might attempt to do this.
The answer is yes, releasing the object passed to init is fine, you
can return something else or nil if needed. joar is right about
autorelease there tho, no point whatsoever.
jkp
On 22 Oct 2005, at 17:35, j o a r wrote:
On 22 okt 2005, at 15.32, Felix Schwarz wrote:
Code sample 1:
Valid. I would have used release, and not autorelease, but it's
not very important. It just seems pointless to use autorelease there.
Code sample 2:
Invalid, unless you call [super init] in "-someOtherInit:", in
which case it's OK.
Same thing about release vs. autorelease applies here too.
Or, in other words, is it ok to autorelease and or release an
object right after "alloc"ation, before it was "init"ialized?
Yes, I guess it is, but I wouldn't do:
I.e. is it ok to do
id someObj = [SomeObj alloc];
[someObj release];
or
id someObj = [SomeObj alloc];
[someObj autorelease];
Simply because it breaks the rule that you should always alloc
+init on the same row.
I also don't really see when you would want to do the above?
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden