Ordering of static destructors on exit
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=S5LQxGk4aDz3gMgChLeYKlncnFlrobMX6nYoyzeWT9NCR9gEcQ93SeMHywRgm/uEN2f5FSKyQkDIwohSj1GUm0h95YUm9hTNSpsRt2f97Q8PiKaHN440+UiTWian+mdWBwCkvsCWRpQYOJLSLRFQpthU6iQWzH+/mHfxT/XbDVE= Hi, I was wondering if anybody can tell me precisely when the destructors of static objects are called. I have been using something like: CClass* CClass::singleton() { static CClass singletonInstance; return & singletonInstance; } inside a framework. This framework is used by a QuickTime component. CASE A: In typical applications, the sequence of events I see on quitting the application is: - the QuickTime component closed - destructor of singletonInstance called - application has exited CASE B: In a recent Cocoa application I've come across I'm seeing: - destructor of singletonInstance called - the QuickTime component closed - application has exited (well - application crashes now, as the singleton is referenced by the QuickTime component) I had thought that static destructors always were called at exit() time, so am a little puzzled how the order is reversed by this Cocoa app. (The destructor and component closing appear to be occurring on the same pthread.) Moving the: static CClass singletonInstance; from inside the function, to outside the function (ie. file scope) restores the ordering to that of CASE A, and avoids the crash. But I don't understand why the change of scope would change the ordering of events... Can anybody shed any light, or point me at any only resources that describe how darwin/gcc orders the calling of static destructors? (This may be a cocoa-dev mailing list question, as I understand Cocoa apps are run/controlled by NSApplicationMain() which may do some special atexit() fiddling...but I thought I'd try here first...) Thanks in advance, Rob. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
Rob Cas