Re: NSAutoreleasePool and static data member constructors
Re: NSAutoreleasePool and static data member constructors
- Subject: Re: NSAutoreleasePool and static data member constructors
- From: Steve Checkoway <email@hidden>
- Date: Thu, 11 Oct 2007 02:33:59 -0700
On Oct 10, 2007, at 9:49 PM, John Stiles wrote:
On Oct 10, 2007, at 5:27 PM, Clark Cox wrote:
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.
I hope by well-understood, you mean that it is well-understood that
the standard does not guarantee the order of initialization between
translation units. The relevant portion of the standard seems to be
3.6.2 [basic.start.init]. To quote from the standard (bah, my copy of
the standard has copy protection, this is quite possibly the dumbest
thing I've ever seen in a document),
The storage for objects with static storage duration shall be zero-
initialized before any other initialization takes places. Zero-
initialization and initialization with a constant expression are
collectively called static initialization; all other initialization
is dynamic initialization. Objects of POD types with static storage
duration initialized with constant expressions shall be initialized
before any dynamic initialization takes place. Objects with static
storage duration defined in namespace scope in the same translation
unit and dynamically initialized shall be initialized in the order
in which their definition appears in the translation unit.
(Little did they seem to realize that I can type the text since I can
read it...)
--
Steve Checkoway
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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