Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Initializing static C++ class variable in a HAL plugin

The HAL itself doesn't have any statically initialized data structures, so that should be fine from the HAL's perspective. In fact, a lot of system frameworks have no static initialization, but some do.

That said, I would be leery of this technique. It is way too sensitive to order-of-operations issues, especially with other entities that also want to do static initialization or +load stuff. I can see where a complex application that had lots of ObjC++ code could get very upset or have some weird bugs.

A lot of times "magic" features like this are just a pain in the butt for app developers since it takes the control out of their hands. The usual place this crops up is when the app developer is trying to optimize her app's loading time. The fact that you trigger HAL initialization (a very expensive operation) before main() is even entered prevents the app from being able to defer that operation until later or do it on another thread.

IMHO, you would be better served if you had a two well defined entry points in your library that the client had to call to set up and then tear down your library. In fact, I would change your library to have no +load methods at all. This puts the control in the hands of the app developer where it should be.

On Feb 3, 2005, at 1:18 PM, Michael Thornburgh wrote:

so i suppose a bigger question is: is it safe/allowed/"not discouraged" to call HAL routines, such as AudioHardwareAddPropertyListener(), at +load time when the program is first starting? the documentation for +load (NSObject) mentions that no guarantees are made about the order of +load being sent in the class hierarchy (vs +initialize). also, this +load is being sent to a (usually) dynamically loaded framework in the app's bundle, but against which the main application object was linked. the docs for +load don't really mention the impact of doing non-objective-C things, though.
i put the AudioHardwareAddPropertyListener() in +load because the semantic i wanted to provide was "if you link in MTCoreAudio, then you'll magically get NSNotifications for audio hardware events like the device list changing and stuff". if hooking up at +load isn't safe, it won't be the end of the world to move this to +[MTCoreAudioDevice initialize], since almost every app will start out with an
[MTCoreAudioDevice attachNotificationsToThisThread];
or getting the device list or a default device or something, which will cause +initialize to happen in that class.
Stéphane's problem is the first issue with my having done this that i've heard of, though. hopefully it wasn't a ticking timebomb waiting to ruin someone's day.


--

Jeff Moore
Core Audio
Apple


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden

This email sent to email@hidden
References: 
 >Re: Initializing static C++ class variable in a HAL plugin (From: Stéphane Letz <email@hidden>)
 >Re: Initializing static C++ class variable in a HAL plugin (From: Jeff Moore <email@hidden>)
 >Re: Initializing static C++ class variable in a HAL plugin (From: Michael Thornburgh <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.