Re: Checkboxes and NSBox titles
Re: Checkboxes and NSBox titles
- Subject: Re: Checkboxes and NSBox titles
- From: John Hörnkvist <email@hidden>
- Date: Wed, 13 Jun 2001 16:47:44 +0200
On Wednesday, June 13, 2001, at 04:18 PM, Jim Correia wrote:
On Wednesday, June 13, 2001, at 09:43 AM, John Hvrnkvist wrote:
id val = [someObject getVal];
[somObject setVal:newVal];
[val doSomething]; // but now val is a dangling pointer because val
was released in setVal
No, you should NOT count on that.
I thought that was the contract foundation objects agreed to. I'll see
if I can find the reference in the docs I am thinking off.
As far as I know, foundation objects do not agree to that. As my example
showed, you certainly shouldn't rely on it.
Using the auto release pool should be avoided; their use can blow up
the footprint of a program immensely.
Like anything, there is no silver bullet. I'm sure there are
appropriate times to use the autorelease pool though.
Autorelease pools can be convenient. They simplify memory management,
and are therefore used a fair bit in tutorials and examples.
However, using autorelease creates significant memory overhead in some
situations. By consistently using release instead of autorelease when it
is possible, you get rid of many memory related problems before they
appear. Further, autorelease can make debugging very difficult.
Autorelease is excellent for handling leaking references, as in
- (id)aValue
{
return [[value copy] autorelease];
}
or
+ (id)something
{
return [[[Something alloc] init] autorelease];
}
Its use in forms like
Something* object=[[[Something alloc] init] autorelease];
[object doSomething];
is simply wasteful. This form is clearer and has less overhead:
Something* object=[[Something alloc] init];
[object doSomething];
[object release];
In some cases you have no reason to care about overhead, but in general
I'd not include get/set methods in that.
Regards,
John Hornkvist
--
ToastedMarshmallow, the perfect Cocoa companion
http://www.toastedmarshmallow.com