Re: AU Properties and Ownership of CF objects
Re: AU Properties and Ownership of CF objects
- Subject: Re: AU Properties and Ownership of CF objects
- From: Mark <email@hidden>
- Date: Tue, 29 Jan 2013 10:46:54 +1100
There is no 'autorelease' of any value supplied as the argument to an AU's SetProperty method, so you need to still manage the lifecycle of a CF object passed between the view & the AU this way.
I would be doing what you suggested, in the AU's UpdateProgramName(a_string) function I would be making a copy of the string argument using one of the available CF functions, and assigning the resulting string to a member variable.
In this scenario it is also important to manually release any currently retained / copied CFString before assigning an incoming string to the member variable.
But as the initial CFString is created with a retain count of 1, you will also need to CFRelease that CFString at the end of the method that creates it (in the View), AFTER the call to SetProperty on the AU has returned.
Cheers,
Mark
On 24/01/2013, at 2:07 PM, Stephen Blinkhorn wrote:
> Thanks Mark,
>
> I should have been more clear. Specifically I'm talking about passing a C struct between view and AU (which I believe is basically a memcpy type operation). Say I have a struct with a CFStringRef member an in the view I have created a new CFStringRef and assigned a struct member to this new string. Now let's say I am using this struct to set a property from the view. In the AU I'll have something like this in my SetProperty() function:
>
> case kCustomAUProperty_StructCFExample:
> {
> SomeStruct *a_struct = (SomeStruct*)inData;
> CFStringRef a_string = a_struct->mStringMember;
> UpdateProgramName(a_string);
> return noErr;
> }
>
> So in this example I'll need to retain a_string or make a copy of it in UpdateProgramName() if I intend to keep the string for later use. I can't see how it could be any different as a_struct will surely be released once the SetProperty call is complete. Is that correct?
>
> Apologies if anyone is feeling a little déjà vu here.
>
> Stephen
>
>
>
> On Jan 23, 2013, at 8:02 PM, Mark <email@hidden> wrote:
>
>> If you create a CF object using any of the provided CF function that contain the words 'create' or 'copy', you are returned a CF object with a retain count of one... you 'own' that object and must CFRelease it at some stage when you are done using the object.
>>
>> Whether one assigns the CF object to a struct member or to a native-typed variable doesn't really enter into the equation... if you assign an 'owned' CF object to a struct member, you still 'own' the CF reference, and still have to deal with releasing the CF object when the struct containing the CF object is no longer needed.
>>
>> HTH,
>>
>> Mark
>>
>>
>>
>>
>> On 24/01/2013, at 3:51 AM, Stephen Blinkhorn wrote:
>>
>>> Hello,
>>>
>>> Thanks to Technical Q&A 1684 I understand the ownership rules for AU properties that are Core Foundation data types (e.g. CFURLRef, CFStringRef etc). Basically, in an AU's GetProperty call you own the reference. But what if you have a CF data type embedded in a C style struct? This isn't really covered but presumably one cannot possibly own a CF reference in this case? Would just like to clarify that before I clean up some memory leaks.
>>>
>>> Thanks,
>>> Stephen
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> Mark Hill
>> MachineCodex Software
>> http://www.machinecodex.com
>>
>>
>>
>
Mark Hill
MachineCodex Software
http://www.machinecodex.com
_______________________________________________
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