Re: Programatically detect if any autorelease pool exists?
Re: Programatically detect if any autorelease pool exists?
- Subject: Re: Programatically detect if any autorelease pool exists?
- From: John Stiles <email@hidden>
- Date: Tue, 5 Sep 2006 15:10:41 -0700
I think you're going to have to write it more like this. Way more
work for you, but it's the only way:
class Stuff
{
public:
Stuff()
{
NSAutoreleasePool * pool = [make autorelease pool];
do stuff
m_importantThing = [[ImportantThing importantThingWithWhatever:0]
retain];
[pool release];
}
void Fn()
{
NSAutoreleasePool * pool = [make autorelease pool];
[m_importantThing useIt];
[pool release];
}
~Stuff()
{
NSAutoreleasePool * pool = [make autorelease pool];
do stuff
[m_importantThing release];
[pool release];
}
protected:
ImportantThing * m_importantThing;
}
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;
}
On Sep 5, 2006, at 3:04 PM, Sean McBride wrote:
On 2006-09-05 16:47, Clark Cox said:
Is there a way to programatically detect if any autorelease pool
exists?
Why? I'm helping with a cross-platform open source library (vtk, if
you're curious) and I'm having a problem with autorelease pools.
The
library is C++ only (there are a few Obj-C++ classes, but that's an
internal implementation detail) and tends to be used in one of
two ways:
in a cross-platform C++ app, or in a normal Cocoa application.
Currently, the library is creating its own NSAutoreleasePool then
releasing it later. This works great in the first case (since cross
platform C++ apps should not be concerned with the fact that the
library's implementation needs an autorelease pool present) but is
problematic in the second case.
Why is it problematic in the second case? That shouldn't cause any
problems.
It's somewhat hard to explain. Basically, it's a timing thing. The
library (vtk) creates its autorelease pool in the ctor of a C++ class
that displays a window (a simplification, but sufficient) and releases
the autorelease pool in the dtor. A client application may of course
create a vtk window at any point during its lifetime, and once it
does,
all other Obj-C objects (related to vtk or not) will end up in the vtk
pool. Then, if the vtk window is closed, that autorelease pool goes
away and flushes objects unrelated to vtk.
So its not as simple as: void LibraryEntryPoint() {create pool, do
stuff, destroy pool, return}.
Basically, I don't want vtk to create an autorelease pool. :) A host
application has its own system of pools, and I don't think a library
should be creating its own. Alas, if I don't create a pool, then
cross-
platform vtk applications (think wxWidgets-type thing) spew
"_NSAutoreleaseNoPool(): Object 0x1b76fb0 of class NSBundle
autoreleased
with no pool in place - just leaking" messages.
That's why I'm hoping to be able to detect at runtime if there is any
pool. Whatever prints that message is able to tell.
I'm certainly open to other ideas. I had really hoped that
NSApplicationLoad() would create a pool if none existed, but it
doesn't
seem to. Maybe there is another way?
Thanks,
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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