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 21:49:16 -0700
On Oct 10, 2007, at 5:27 PM, Clark Cox wrote:
On 10/10/07, Uli Kusterer <email@hidden> wrote:
Am 11.10.2007 um 00:19 schrieb Clark Cox:
On 10/10/07, Uli Kusterer <email@hidden> wrote:
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.
Smart pointers take care of this for you.
Only if their constructors are called. But as we found out, they
are on 10.4, but if you deploy on 10.3 you'll want to use regular
pointers and new and delete your C++ objects.
The rest of your e-mail is spot on:
Global autorelease pool or pool created before main() - bad idea
Throwing exceptions across language boundaries - bad idea
You forgot: Implicitly or explicitly relying on initialization
order of globals or class-static variables - bad idea
This is really a matter too few C++ programmers are aware of: If
you have two object-type globals, and one uses the other from its
constructor, this is *a programming error*.
While I am currently away from my mac (and therefore my copy of the
standard) I do believe that the order of construction is well-defined
if the two objects are defined in the *same translation unit*. Though
I can't say that I've ever relied on that (nor do I plan to) :)
This is correct, and it is safe to rely upon. The standard dictates
that global variables in a single translation unit are constructed
"in order," from the top of the translation unit down. And of course
the destructors are invoked in reverse order, from the bottom up.
Between translation units, this way lies madness. Among the C++ savvy
coders I know, this is well understood. It's better to have global
objects which initialize themselves correctly on first use. We
actually have some classes dedicated to cleaning up objects in the
proper order; each global object specifies what things it relies on
(if any), and this turns into a directed acyclic graph which
determines shutdown order. It works well in practice but it's
difficult to educate people on how to use it. (It is also good
because it can immediately assert if there is a cyclic dependency.)
But in the general case, I believe you are correct.
You cannot know whether
your target object has already been constructed at the time the
constructor uses it.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
--
Clark S. Cox III
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:
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