• 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: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful


  • Subject: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
  • From: Wade Tregaskis <email@hidden>
  • Date: Mon, 4 Feb 2008 18:33:05 -0800

Then take a look again at the method prototype:

- (const char *)UTF8String; // Convenience to return null- terminated UTF8 representation

Can you clearly and concisely articulate why the pointer returned from
this particular method requires a __strong qualifier?

Yes. You're trying to store the pointer somewhere besides a root.

- (const char *)hexString
{
  char *hexPtr = NULL;
  asprintf(&hexPtr, "0x%8.8x", myIvar);
  return(hexPtr);
}

Now what?

asprintf() is documented to place a result in hexPtr that requires you call free() upon it. Your code needs to do that regardless of whether you adopt retain/release or GC. The documentation discusses how GC replaces the retain/release/dealloc/autorelease reference counting. You should not infer that it also replaces free() or other memory models found on the system like Carbon or C++.

I believe Mr. Engelhart is trying to express the ambiguity of current C-typed methods, such as UTF8String, which don't clearly - in C/ObjC - indicate their memory management scheme. As noted, NSString's UTF8String returns autoreleased/GC'd memory, while hexString (above) returns malloc'd memory. But their return values are typed identically. This is still something you need to think about with non- GC, though, because you'd need to know whether you must explicitly free() the returned value or not. Thus why this is documented for that method.


I think the core of the issue is that any method that returns pointers is potentially doing magic behind your back, relying on autorelease/ GC, which previously you didn't really need to care about quite the same; the returned string was seemingly always valid (and maybe you leaked, at worst). This works okay with autorelease, because the points at which autorelease pools are flushed are well defined and more or less controllable. However, with GC you now have the potential for collection at any time, so - although it may be rare - it's possible for old code, that relied on those particular autorelease semantics, to break.

It would seem to me that, in order to completely expose these semantics, voodoo methods such as this would need to define their return value as something like "autoreleased const char*". That way you have the extra semantics of knowing that the returned pointer is autoreleased/GC'd, and the compiler could even issue a warning if you try to assign it to a non-strong variable. [[ bonus points to the gcc guys if they can get the compiler to warn you that you're using an autoreleased variable beyond a pool flush, without retaining it first... I hate those kinds of errors ]]

Wade
_______________________________________________

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: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
      • From: Quincey Morris <email@hidden>
References: 
 >Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful (From: Ben Trumbull <email@hidden>)

  • Prev by Date: Re: NIB file "includes"?
  • Next by Date: Re: PDFAnnotationLine problem
  • Previous by thread: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
  • Next by thread: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
  • Index(es):
    • Date
    • Thread