Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to set NavDialogCreationOptions strings

on 7/29/04 5:05 PM, Scott Thompson <email@hidden> wrote:

>
> On Jul 29, 2004, at 6:17 PM, Frederick Cheung wrote:
>
>> On 30 Jul 2004, at 00:37, Kurt Bigler wrote:
>>
>>>> gs just replace
>>>> the ones that are there with your own CFStringRefs.
>>>>
>>>>> First I thought these strings must be mutable else it would be
>>>>> unsafe to
>>>>> modify the strings in NavDialogCreationOptions. But maybe I am
>>>>> expected to
>>>>> dispose the old strings and create new ones to assign to the fields?
>>>>> Otherwise--I could not find an API to reassign the value of a
>>>>> mutable string.
>>>>> Doing a replace operation seems like overkill.
>>>>>
>>>> They are not mutable (if they were they would be
>>>> CFMutableStringRefs).
>>>> I wouldn't release the strings either (you didn't create them so you
>>>> shouldn't release them). Just assign your own CFStringRefs into the
>>>> fields and ignore the default values.
>>>
>>> Why isn't that a memory leak?
>>>
>> Well it's not a memory leak if you don't own those strings.
>
> It could, potentially, be a memory leak, but there's no way for you to
> know.
>
> I strongly suspect, however, that it is not.
>
> At the very least, the operating system is probably expecting to use
> the same strings every time you create default dialog options. If you
> were to free those strings out from under the Navigation Services
> framework, that would be a Bad Thing
>
> If I had to guess at how Navigation services is implemented, however, I
> would say that you couldn't really "free" those strings even if you
> tried. The operating system is probably creating a CFString from a
> static string

Even if the string is static the reference object itself might not be, I
would have said probably is not, but I suppose I can't predict what tricks
might be done under the hood.

> somewhere using the same technology that sits behind the
> CFSTR macro. With such objects you can pretty much think of the string
> as being created at compile-time and stored in the program's global
> data.
>
> As I understand, these strings can actually participate in
> retain-release semantics. Since the memory can't actually be freed,
> however, releasing them enough that they should be freed is actually
> an unsupported operation with undefined behavior (at least according to
> engineers at Apple).
>
> The thing to keep in mind here, however, is that you didn't allocate
> those strings so you are not responsible for releasing them. If it is
> a memory leak... it's the OSes fault and not yours.

Well I actually said dispose, but I really meant release in the sense of
decrementing the reference count (retain count?) with dispose happening at
0. Mind you I don't know much about how OS X *uses* those concepts in its
APIs.

But I figured if as you say "retain-release semantics" is being used then it
is a Bad Thing to blast a reference for which a retain count was
incremented because that prevents the OS from being able to dispose it.

It just seems to me that any use of an object type that supports
retain-release semantics requires a spec that describes any special-case
requirements. In lack of any such requirements it seems like retain-release
semantics is implied. But these are not really "smart pointers" and so it
may not be a convention that a copy of a reference is associated with an
incremented retain count. From the outside this is all too confusing. The
very use of a CFString in an OS data structure for me implies all this extra
overhead of unknown semantics. Maybe there is a global policy about this
defined somewhere?

Blasting a CFStringRef in a data structure set up by the OS looks to me like
it might be a bad thing. If it isn't bad and the OS is written to assume
coders are not worrying about such issues, then that also looks like a
potential problem to me and suggests that some specification would be a good
idea. Maybe there are just a bunch of policies that are well-understood by
people who have been using these concepts in OS X for years, and no one has
written these things down.

-Kurt
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: how to set NavDialogCreationOptions strings (From: Scott Thompson <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.