Re: NSAutoreleasePool and static data member constructors
Re: NSAutoreleasePool and static data member constructors
- Subject: Re: NSAutoreleasePool and static data member constructors
- From: Uli Kusterer <email@hidden>
- Date: Wed, 10 Oct 2007 21:39:41 +0200
Am 10.10.2007 um 16:28 schrieb Clark Cox:
but never raw pointers. Raw pointers to C++ objects should not be used
as Objective-C instance variables. Additionally, except for simple,
transient Obj-C objects, the C++ objects should be "owned" by the
Objective-C objects, not the other way around.
Errr... I'm not sure whether that was a 10.3-only limitation, but I
distinctly remember that Objective C did not call C++ constructors
for its instance variables. The compiler option to activate this has
been around for a while, but AFAIK the C++ runtime currently shipping
with 10.4 doesn't support that option yet. So, I don't think you can
use C++ smart pointers and the likes as instance variables. You /have
to/ use pointers and new and delete them properly.
For static and global variables, one really can not rely on
initialization order (except for constant initializer values), and
for that reason one shouldn't create any more complex object in an
initializer for one of these variables. This applies not only to
mixed-language settings, but also to any "pure" C++ code. What one
should really do is
a) use lazy initialization upon first use (go through an accessor to
get at a singleton, not use the global directly)
b) be darned careful to avoid circular dependencies
If b is not an option, one should at least do the initialization
after main() has been entered. Anything else just isn't safe or
reliable, nor deterministic enough. Once you've done that, you have a
function that gets called, and in that function you can set up and
tear down an autorelease pool for that one call. And as with other
uses of ObjC, any objects you need to keep around yourself outside
this pool should be retained.
It is not a good idea to try and create a "global autorelease pool"
outside main, or for that matter even inside main, because this is
essentially the same as a leak. Any objects added to this pool will
stay around and won't be released until your application quits. All
you do is shut up the console message, but you're not plugging the
actual leak.
Also, watch out for exceptions when integrating C++ and Objective C.
Neither C++ nor ObjC like it when you throw and exception of either
type through code of the other type, just like you shouldn't throw an
exception through OS code. This may also be difficult, as the
standard CarbonEventHandlers installed on Cocoa windows in a Carbon
app don't install exception handlers before they call into Cocoa, so
you'll have to fix that yourself.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
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