• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Initializing static C++ class variable in a HAL plugin
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 13:18:25 -0800


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.

-mike


On Feb 3, 2005, at 12:43 PM, Jeff Moore wrote:

I just read more about this ObjC +load method. Apparently it executes in a special context that has lots of rules about what you can and can't do, including restrictions on what functions you can call and what objects you can touch. Judging from your experience, I imagine that it is also executing before any C++ static initializers have run which makes what you are trying to do pretty much impossible. You'll need to defer the work until after +load finishes executing.


[...]

_______________________________________________
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
  • Follow-Ups:
    • Re: Initializing static C++ class variable in a HAL plugin
      • From: Jeff Moore <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>)

  • Prev by Date: Re: problems compiling SDK PublicUtility classes
  • Next by Date: Re: Initializing static C++ class variable in a HAL plugin
  • Previous by thread: Re: Initializing static C++ class variable in a HAL plugin
  • Next by thread: Re: Initializing static C++ class variable in a HAL plugin
  • Index(es):
    • Date
    • Thread