Re: Initializing static C++ class variable in a HAL plugin
Re: Initializing static C++ class variable in a HAL plugin
- Subject: Re: Initializing static C++ class variable in a HAL plugin
- From: Michael Thornburgh <email@hidden>
- Date: Thu, 3 Feb 2005 16:37:57 -0800
jeff: this is an excellent point. the next release of MTCoreAudio will
address this issue.
-mike
On Feb 3, 2005, at 2:16 PM, Jeff Moore wrote:
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:
This email sent to email@hidden