On Nov 29, 2006, at 12:19 PM, Stefan Werner wrote:
On Nov 29, 2006, at 6:19 PM, Shawn Erickson wrote:
What you should do is ensure an autorelease pool is in place during
any method call that sends objective-c messages and released on exit
from such methods (note the that in a Cocoa application an
autorelease
pool is managed for you on the main thread).
Well, I did try different patterns of creating/destroying the
autoreleasepools with no success so far, including creating/
destroying one per thread. Making it a member of the C++ class
seemed like the most convenient way, but I see now that this only
works as long as only one instance of that class exists at a time
(which actually is true in my case).
View it more as analogous to a C++ class that should only exist on
the stack - it should never be stored in anything other than a local
variable.
For example, if you had a class that saved/restored some drawing
context (following the common C++ pattern of "resource allocation is
initialization"), you wouldn't allocate it in one routine, and then
destroy it in another - you declare the object (which save current
state and set it to whatever is desired), do stuff, and then
implicitly destroy the object when your code exits the scope (which
restores the state back to what it was). Same principle, but
Objective-C doesn't (currently) have stack based objects.
