Re: NSAutoreleasePool and static data member constructors
Re: NSAutoreleasePool and static data member constructors
- Subject: Re: NSAutoreleasePool and static data member constructors
- From: Eyal Redler <email@hidden>
- Date: Wed, 10 Oct 2007 16:21:50 +0200
On Oct 10, 2007, at 15:20, Erik Buck wrote:
I have a C++/Objective-C application which has some constructors for
static data members accessing autorelased Objective-C objects and I
get messages like this in the console:
* _NSAutoreleaseNoPool(): Object 0xd06e70 of class NSCFString
autoreleased with no pool in place - just leaking
Obviously, I need to setup an autorelase pool before all the static
member construction. Is there a way to do this?
No.
Constructors for C++ static data members are all called before main
(). You could create an NSAutorleasePool within a static data
member's constructor, but the ANSI/C++ standard does not define any
order for static data member constructors to be called, and in
fact, every time you link your application, the order will likely
change.
My advice to you is to not mix Objective-C and C++ in the way you
are attempting. Keep the separation clear. If possible, do not
use any non-pointer instances of C++ classes as instance variables
of Objective-C classes or visa versa. The implementation of C++
classes should access Objective-C objects by pointer only
(obviously), and the reverse is also true. Objective-C methods
should access C++ instances by pointer only.
Thanks Eric, I am not using non pointer C++ objects inside objective
c objects but there are some C++ objects which access services that
are implemented in Objective-C and are auto-releasing objective C
objects.
I was hoping to find some sort of "pre startup" opportunity when the
executable is loaded in order to create the initial auto-release pool
there, isn't there some routine that gets called to initialize the
executable?
Avoiding using static non pointer objects would be the best solution,
I guess, but I'm porting code from windows and doing this would be
quite radical.
_______________________________________________
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