Re: Re: Programatically detect if any autorelease pool exists?
Re: Re: Programatically detect if any autorelease pool exists?
- Subject: Re: Re: Programatically detect if any autorelease pool exists?
- From: "Michael Ash" <email@hidden>
- Date: Wed, 6 Sep 2006 00:10:36 -0400
On 9/5/06, Chris Suter <email@hidden> wrote:
> It will help if you have a C++ class which manages the autorelease
> pools by automatically releasing it when it goes out of scope. Then
> it becomes a little less wordy:
>
> class Stuff
> {
> public:
> Stuff()
> {
> AutoNSAutoreleasePool pool;
> do stuff
> m_importantThing = [[ImportantThing importantThingWithWhatever:
> 0] retain];
> }
> void Fn()
> {
> AutoNSAutoreleasePool pool;
> [m_importantThing useIt];
> }
> ~Stuff()
> {
> AutoNSAutoreleasePool pool;
> do stuff
> [m_importantThing release];
> }
> protected:
> ImportantThing * m_importantThing;
> }
I'm not sure how Objective C exceptions work with Objective C++, but
there's a chance this would break them if you needed them.
The two exceptions systems do not interact in any way. Therefore a C++
exception will fall right through an ObjC @try block, and vice versa.
Throwing an ObjC exception through C++ code is likely to lead to
disaster, as it will bypass all destructors for C++ stack objects.
(The other way is likely to lead to disaster too, as @finally blocks
will not execute and @synchronized blocks will fail to relinquish
their lock, but this scenario is somewhat more likely to come out
well.) For full paranoia, any code which exposes a C++ interface but
uses ObjC internally should wrap all ObjC in both an autorelease pool
as shown above as well as an ObjC exception handler.
Mike
_______________________________________________
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