retain+release (Re: kAudioUnitProperty_ContextName)
retain+release (Re: kAudioUnitProperty_ContextName)
- Subject: retain+release (Re: kAudioUnitProperty_ContextName)
- From: Brian Willoughby <email@hidden>
- Date: Tue, 27 Jul 2004 16:12:25 -0700
[ >> 2) ContextName is not covered in CF_AU_Properties.text nor are its
[ >> CoreFoundation semantics covered in the regular docs for the AU API:
[ >> /Developer/Documentation/CoreAudio/AudioUnits/Topics/
[ >> au_properties.html#kAudioUnitProperty_ContextName
[ >> I am guessing that it is the norm (the AU creates or retains the
[ >> value for the client on GetProperty, and retains the new value on
[ >> SetProperty), but it seems to me like this should be explicitly
[ >> stated somewhere.
[ > I'd definitely vote for following the norm.
[
[ When the property is Set - the AU should retain the string (so
[ ultimately it might have the only reference to it).
So far, so good...
[ When the property is retrieved, the AU should also retain the string,
[ so it always has a retain on the string it is holding. The host should
[ release the string it retrieves from Get Property when it is finished
[ with it.
Perhaps I misunderstand, but this seems to break the typical object-oriented
design paradigm. Retain and release pairs should never be handled by different
objects. Each use of a string object should be retained and then later
released by the same object. This isn't always possible, though, which is why
autorelease was designed, but autorelease only works when there is a pool in
place. In the case you describe above, if the AU retains a string that it is
returning to the host, then it should autorelease that string. The host should
be responsible for retaining the string only if it needs to hold on to the
string longer than the current pool context, if any, and release it later.
The other alternative would be for the host to retain the string as soon as it
receives it from Get Property, and release it when done.
What I have described was established as a standard design paradigm in
Objective C, and should be confirmed throughout the Cocoa documentation. I'm
less familiar with the standard C implementations of these concepts, but I
really hope the ease of use has not been compromised by increasing the
responsibilities of one object for another object.
[ The property can be cleared by setting the property with a NULL value
[ (so the AU *has* to check for NULL before retaining the value when the
[ property is set)
No problem.
Brian Willoughby
Sound Consulting
_______________________________________________
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.