Re: Accessors Question
Le 12 juin 08 à 19:21, Jeff LaMarche a écrit : Lately, I've started to see accessors of the following sort: - (NSString *)foo { return [[foo retain] autorelease]; } rather than just - (NSString *)foo { return foo; } What is the purpose or benefit of doing this? It seems to me that this would add things unnecessarily to the autorelease pool, and I can't see a benefit to be had. I've seen it in places that make me think there must be a reason (e.g. sample code from Apple), so I'm guessing I'm missing something. Is there some benefit due to GC? If so, should this construct be used without GC or only with? Thanks, Jeff I think the purpose is describe in the writing accessor guide : http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAccessorMethods.html As with values manufactured by class convenience methods, the returned object is autoreleased in the current scope and thus remains valid if the property value is changed.” This is mainly to prevent this kind of issue: NSString *foo = [myObject foo]; [myObject setFoo:nil]; // setter release the foo ivar = foo is no longer pointing on a valid memory location. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Accessors Question
On Jun 12, 2008, at 1:21 PM, Jeff LaMarche wrote: Lately, I've started to see accessors of the following sort: - (NSString *)foo { return [[foo retain] autorelease]; } I believe this is in case of something like this: NSString *myFoo = [myObject foo]; // ... stuff that causes myObject to be deallocated ... NSLog(@%@, myFoo); // --- myFoo might be invalid I definitely saw this pattern mentioned before GC, so it doesn't have to do with that. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Accessors Question
On Jun 12, 2008, at 10:21 AM, Jeff LaMarche wrote: Lately, I've started to see accessors of the following sort: - (NSString *)foo { return [[foo retain] autorelease]; } rather than just - (NSString *)foo { return foo; } What is the purpose or benefit of doing this? It seems to me that this would add things unnecessarily to the autorelease pool, and I can't see a benefit to be had. I've seen it in places that make me think there must be a reason (e.g. sample code from Apple), so I'm guessing I'm missing something. Is there some benefit due to GC? If so, should this construct be used without GC or only with? Assuming there is a -setFoo: that is implemented as retain-new / release-old, as is typical... Consider: id b = [something foo]; [something setFoo: @bar]; [b length]; The above will crash in the non retain/autorelease case, but not otherwise. b.bum smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Accessors Question
On Jun 12, 2008, at 1:31 PM, Jean-Daniel Dupas wrote: This is mainly to prevent this kind of issue: NSString *foo = [myObject foo]; [myObject setFoo:nil]; // setter release the foo ivar = foo is no longer pointing on a valid memory location. I hadn't thought of this case. Thanks for the pointer to the docs -- I now see there is a vulnerability in the accessors I've been writing. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Accessors Question
Hello, Although I prefer the safer accessors, there has been one case where I had no choice but to return the main object pointer: - (NSString *)foo { return foo; } In my app I had a method that was populating a custom cell with a few elements. Depending on the data source, I had to construct the strings in different ways. Since this string had to be constructed with up to 5 elements, when the table view had many rows, performance suffered greatly during sort and memory consumption spiked tremendously due to a barrage of newly allocated objects. I ended up writing something like: // Private version used only for performance - (NSString *)_foo { return foo; } // Safer version used in all other cases - (NSString *)foo { return [[foo retain] autorelease]; } By using '_foo' during sorting I increased speed noticeably, while reducing the memory footprint. -- Tito On 12 Jun 2008, at 11:27 AM, Jens Alfke wrote: On 12 Jun '08, at 10:41 AM, Andy Lee wrote: I hadn't thought of this case. Thanks for the pointer to the docs -- I now see there is a vulnerability in the accessors I've been writing. This is kind of a religious issue. Some people like the safer accessors. Some people see them as a very expensive* workaround for a problem that rarely occurs. I'm firmly in the latter camp. I've never used this 'safe' form of accessor, and have only rarely run into the kind of crash it prevents; and it was always pretty easy to track down and fix. (The fix is just for the caller to retain the value it got from the accessor, then release it when it's done using it.) Another alternative is to leave the getters simple, but change the _setter_ methods to autorelease the old value instead of releasing it; that prevents this same crash, but is less expensive because setters are much more rarely called than getters (and -autorelease isn't much more expensive than -release.) —Jens * A basic accessor requires one or two machine instructions to do the actual work; whereas -retain and -autorelease involve extra method dispatches that each acquire a global lock and do a hashtable lookup. Obviously any one call isn't going to take a noticeable amount of time, but accessor calls are so damn ubiquitous that this can have an overall impact on app performance in some cases. Not to mention memory usage, since autoreleased objects have a longer lifespan and can build up during loops.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/tciuro%40mac.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Accessors Question
Out of curiosity, does anyone know what the synthesized accessors look like when you specify retain? Are they The safe or unsafe ones? Sent from my iPhone On Jun 12, 2008, at 12:02 PM, Tito Ciuro [EMAIL PROTECTED] wrote: Hello, Although I prefer the safer accessors, there has been one case where I had no choice but to return the main object pointer: - (NSString *)foo { return foo; } In my app I had a method that was populating a custom cell with a few elements. Depending on the data source, I had to construct the strings in different ways. Since this string had to be constructed with up to 5 elements, when the table view had many rows, performance suffered greatly during sort and memory consumption spiked tremendously due to a barrage of newly allocated objects. I ended up writing something like: // Private version used only for performance - (NSString *)_foo { return foo; } // Safer version used in all other cases - (NSString *)foo { return [[foo retain] autorelease]; } By using '_foo' during sorting I increased speed noticeably, while reducing the memory footprint. -- Tito On 12 Jun 2008, at 11:27 AM, Jens Alfke wrote: On 12 Jun '08, at 10:41 AM, Andy Lee wrote: I hadn't thought of this case. Thanks for the pointer to the docs -- I now see there is a vulnerability in the accessors I've been writing. This is kind of a religious issue. Some people like the safer accessors. Some people see them as a very expensive* workaround for a problem that rarely occurs. I'm firmly in the latter camp. I've never used this 'safe' form of accessor, and have only rarely run into the kind of crash it prevents; and it was always pretty easy to track down and fix. (The fix is just for the caller to retain the value it got from the accessor, then release it when it's done using it.) Another alternative is to leave the getters simple, but change the _setter_ methods to autorelease the old value instead of releasing it; that prevents this same crash, but is less expensive because setters are much more rarely called than getters (and -autorelease isn't much more expensive than -release.) ―Jens * A basic accessor requires one or two machine instructions to do the actual work; whereas -retain and -autorelease involve extra method dispatches that each acquire a global lock and do a hashtable lookup. Obviously any one call isn't going to take a noticeable amount of time, but accessor calls are so damn ubiquitous that this can have an overall impact on app performance in some cases. Not to mention memory usage, since autoreleased objects have a longer lifespan and can build up during loops.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/tciuro%40mac.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Accessors Question
On Jun 12, 2008, at 12:20 PM, Jeff LaMarche wrote: Out of curiosity, does anyone know what the synthesized accessors look like when you specify retain? Are they ' The retain/autorelease policy is dictated by the atomicity of the property. By default, object properties are returned with retain/autorelease; if you specify 'nonatomic' then they're simply returned. http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_5_section_3.html#//apple_ref/doc/uid/TP30001163-CH17-SW2 For a discussion of other aspects of accessor methods, see http://www.stepwise.com/Articles/Technical/2002-06-11.01.html (although some of that is now out-of-date). mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]