Re: NSAutoreleasePool and static data member constructors
Re: NSAutoreleasePool and static data member constructors
- Subject: Re: NSAutoreleasePool and static data member constructors
- From: John Stiles <email@hidden>
- Date: Wed, 10 Oct 2007 12:42:19 -0700
C++ objects as part of ObjC objects works OK in 10.4 (they are
properly constructed/destructed), if you enable a compiler flag.
It's 10.3 where it won't work.
On Oct 10, 2007, at 12:39 PM, Uli Kusterer wrote:
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:
40blizzard.com
This email sent to email@hidden
_______________________________________________
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