Re: CF Types and AU
Re: CF Types and AU
- Subject: Re: CF Types and AU
- From: Bill Stewart <email@hidden>
- Date: Sat, 9 Aug 2003 19:16:31 -0700
On Saturday, August 9, 2003, at 06:55 PM, Marc Poirier wrote:
>
Thanks very much for the thorough overview. It is very helpful. One
>
question still remains, though: how does the host handle the
>
CFStrings in
>
the AUPreset struct when the host gets the FactoryPresets property?
The CFArray should be released of course, by the host when the presets
are returned, and its finished with this array.
Because the data that is contained within this array (its elements),
are *not* CF objects, then when the array is released (in the
implementation we've done for the reverb at least), the array elements
are not released. Thus, our implementation assumes (which it does),
that the CFString names do not require releasing (we're just returning
essentially static strings)...
(Here's the code we use for that):
ComponentResult AUMatrixReverb::GetPresets ( CFArrayRef *
outData) const
{
if (outData == NULL) return noErr;
CFMutableArrayRef theArray = CFArrayCreateMutable (NULL,
kNumRoomPresets, NULL);
for (int i = 0; i < kNumRoomPresets; ++i)
CFArrayAppendValue (theArray, &sRoomPresets[i]);
*outData = (CFArrayRef)theArray;
return noErr;
}
The important point is the creation of the CFArrayCreateMutable with
the two NULL args - the third argument is a CFArrayCallBacks arg. If
this is NULL, then the defined behaviour is that the array elements are
not retained (or released) - this is the correct argument to pass when
storing non-CF types into an array like this, *and* retain and release
on the array should do nothing.
So, in the reverb case, this is fine, because these strings are static,
will always be valid, don't need to be released when the array is
released (or retained). (We do now also localise the preset name
strings, but that is only done once, and its the localised name that is
returned and kept in sRoomPresets).
If you are generating these names dynamically, then to correctly
retain/release these strings, you'd have to define the CFArrayCallBacks
struct, and implement the retain release semantics to correctly retain
or release the strings contained in presets in the array.
If you are releasing (or otherwise using the strings you give to this
array), then you should also ensure that you do not release these
WITHOUT defining these callbacks (otherwise, you could release strings
that the host/caller may still use at a later date)
We've actually seen crashes with some units doing this and the
validator has been modified to try to cause this crash, and if I've
been unsuccessful with my first attempt I'll try again:) !
Essentially, as with the other CF properties that an AU returns, once
returned, the CF Object really becomes the property of the caller (or
host) - the AU cannot disregard this contract and either re-use these
CF objects, or release CF objects that are contained (either in this
array or in the preset/class info dictionary) either, without defining
these semantics.
Thus in AUBase::SaveState, the CF objects are created each time the
state is saved, and the AU retains no knowledge of these.
(The one exception to this semantic was the CurrentPreset property - so
we've deprecated that property and replaced this with the
PresentPreset, so that the semantic applies in this case as well).
Does that all make sense?
Bill
Thanks for raising this Marc - meant to comment on this (I'll make sure
this is added to the SDK docs)
>
>
Thanks,
>
Marc
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.