Re: NSAutoreleasePool and static data member constructors

FROM : John Stiles
DATE : Wed Oct 10 21:42:19 2007

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_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/jstiles%
> 40blizzard.com
>
> This email sent to <email_removed>