Re: Performance problem with GC enabled
Re: Performance problem with GC enabled
- Subject: Re: Performance problem with GC enabled
- From: Louis Gerbarg <email@hidden>
- Date: Fri, 13 Mar 2009 13:11:12 -0400
On Fri, Mar 13, 2009 at 12:04 PM, Paul Sanders <email@hidden> wrote:
>
> (Off topic again): Call me old-fashioned, but I don't like autorelease pools
> all that much. I believe Cocoa could have gotten along just fine without
> them, had they never been invented. I prefer C++-style 'smart pointers'
> that delete (or release) themselves when they go out of scope. That way you
> avoid the loss of determinism and potential memory usage peaks that
> autorelease pools introduce and it's really not painful writing code that
> way. It's a pity that Objective-C doesn't support such a construct - life
> would have been so much easier. But it's far too late now.
Autorelease pools exist explicitly for passing things out of scopes
("return [retval autorelease];"), otherwise you have to deal with
substantially more complicated ownership semantics for all methods
that return objects. The fact that people have overloaded them to
emulate scoped release a has more to do with people not wanting to
have to cleanup after themselves and the autorelease infrastructure
already existing. Now, having said that, I don't tend to use
autoreleased objects inside a scope they won't escape because I would
rather not bloat my apps high watermark and fragment my zones.
Instead, I do something along these lines:
#define autoscoped __attribute__((cleanup(releaseObject)))
static inline
void releaseObject(id *object) {
[*object release];
}
- (void) demo {
autoscoped NSArray *myArray = [[NSArray alloc] init];
//do some stuff
}
The autoscoped macro tags the lval with an attribute that causes the
cleanup function to be called when the lvals scope disappears.
It is not quite the same as a smart pointer, but it does allow me to
have objects automatically released when their scope disappears,
without causing autorelease traffic.
Louis
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden