Skip navigation.
 
mlRe: NSAutoreleasePool and static data member constructors
FROM : Clark Cox
DATE : Wed Oct 10 16:28:06 2007

On 10/10/07, Erik Buck <erik.<email_removed>> 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.


In general, I agree. However, I'd argue that when using C++ objects as
Objective-C instance variables they should fall into one of these
categories:
1) "value" types. (i.e. Types that present an interface similar to
built-in types std::string, big num types, etc.)
2) Containers (i.e. std::vector, std::set, etc.)
3) Smart pointer types (shared_ptr, auto_ptr, etc.)

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.

--
Clark S. Cox III
<email_removed>