• 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: NSAttributedString crashes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSAttributedString crashes


  • Subject: Re: NSAttributedString crashes
  • From: "Gerriet M. Denkmann" <email@hidden>
  • Date: Fri, 04 Mar 2011 07:20:52 +0700

On 4 Mar 2011, at 01:10, Matt Neuburg wrote:

> On Tue, 01 Mar 2011 16:15:09 +0700, "Gerriet M. Denkmann" <email@hidden> said:
>>
>> On 1 Mar 2011, at 15:53, Kyle Sluder wrote:
>>
>>> On Tue, Mar 1, 2011 at 12:45 AM, Gerriet M. Denkmann
>>> <email@hidden> wrote:
>>>> So obviously NSAttributedString does NOT return [ [ aFont retain ] autorelease ] but just some internal pointer.
>>>>
>>>> Is this documented somewhere?
>>>
>>> In the Memory Management Programming Guide:
>>> http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAccessorMethods.html#//apple_ref/doc/uid/TP40003539-SW6
>>>
>>> --Kyle Sluder
>>
>> As far as I can see, this article talks about different ways to implement setters and getters.
>> Do you want to imply that, whenever I get some object from AppKit, I have to retain it until I no longer need it?
>>
>> Would be a safe thing to do. But also tedious. And in all my past experience this was never necessary.
>> So I thought that the "Technique 1" of the linked article (returning [[someObject retain] autorelease]) was the standart practice employed by AppKit.
>
> I've been thinking about this exchange, and I would propose that you consider it like this:
>
> Suppose you've got an NSArray and you fetch its element objectAtIndex:0. And suppose you now let go of the array (release) and it is destroyed. Do you expect the fetched element to persist without your having retained it? You do not; you know darned well that a collection doesn't behave like that. The collection *owns* its elements and will release them when it is released. All you got when you called objectAtIndex:0 was a pointer. If you want a share in its ownership, you must *take* ownership.
>
> Here's another example. Suppose you've got a UIView and you ask for its subviews. Do you imagine that asking for this property gives you ownership of those subviews? You do not. Similarly for *any* property of *any* object. You *never* imagine that a fetched property is somehow magically *giving* you ownership; it's just showing you a value.
>
> So what I'm trying to show you is that when you've got an object that owns stuff, you *never* expect that that object will dispense the stuff it owns while handing you a share in ownership. You *always* take ownership if you want that stuff to persist beyond the object that dispenses them. Ownership is *never* something you are magically given. It is always something that you must take if you want it.

Yes, I fully agree.

But, taking my original example:

NSAttributedString * attributedString = ...
NSFont *aFont = [ attributedString attribute: NSFontAttributeName  atIndex: 0  effectiveRange: NULL ];
NSString *fontName = [aFont fontName];
[ attributedString release ];

Now aFont no longer exists.
So fontName, being a property of the no longer existing aFont, should have vanished also, shouldn't it?

But in my case, fontName is still valid.
Maybe the fontName method really returns [[fontName retain]autorelease] (as I wrongly assumed all methods did) or some magical entity keeps a handle on all font names, or this name is a constant string decared in AppKit, or whatever.

But this did add to my confusion.

Kind regards,

Gerriet.

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: NSAttributedString crashes
      • From: Kyle Sluder <email@hidden>
References: 
 >Re: NSAttributedString crashes (From: Matt Neuburg <email@hidden>)

  • Prev by Date: Re: Setting a delegate on a UITextField
  • Next by Date: Re: NSAttributedString crashes
  • Previous by thread: Re: NSAttributedString crashes
  • Next by thread: Re: NSAttributedString crashes
  • Index(es):
    • Date
    • Thread