Re: Objective-C Question
Re: Objective-C Question
- Subject: Re: Objective-C Question
- From: Dave <email@hidden>
- Date: Wed, 13 Mar 2013 10:07:30 +0000
On 13 Mar 2013, at 09:24, Markus Spoettl wrote:
On 3/13/13 9:36 AM, Dave wrote:
On 12 Mar 2013, at 21:34, Graham Cox wrote:
On 13/03/2013, at 6:53 AM, Dave <email@hidden> wrote:
If that is the case, then how do you signal to the compiler/
analyzer that you
are returning a retained object?
In general you shouldn't return a retained object (unless it's
temporarily
retained and will be autoreleased of course)
Why? Where does it say this?
https://developer.apple.com/library/mac/#documentation/Cocoa/
Conceptual/MemoryMgmt/Articles/mmRules.html
And Autorelease is evil and should never be used if it can be
avoided!
Nonsense.
Obviously, it isn't evil, but from experience of working on 5 or more
major iOS applications, I've found most bugs were caused as a
consequence of autorelease, that's why I avoid it if possible. I
don't have a problem with memory management, it's simple as long as
you follow the rules.
Avoiding autorelease makes it run faster anyway and makes the whole
app more robust in general. Autorelease in the wrong hands can cause
massive inefficiencies that you'd never code otherwise, here are some
examples of what I mean:
-(NSString*) processString:(NSString*) theString
{
NSString* myWorkString;
myWorkString = [theString stringByReplacingOccurencesOfSting:@"/b"
with:@"BOLD"]; //1
myWorkString = [theString stringByReplacingOccurencesOfSting:@"/i"
with:@"ITALICS"]; //2
myWorkString = [theString stringByReplacingOccurencesOfSting:@"/u"
with:@"UNDERLINE"]; //3
myWorkString = [theString stringByReplacingOccurencesOfSting:@"*"
with:@"ASTERISK"]; //4
myWorkString = [theString stringByReplacingOccurencesOfSting:@"&"
with:@"AMPERSAND"]; //5
myWorkString = [theString stringByReplacingOccurencesOfSting:@"$"
with:@"DOLLAR"]; //6
and so on................
return myWorkString;
}
This code creates 5 strings that are not needed and will clog up
memory until the runloop is called or the pool is drained. Imagine
there were 30 such replacements going on and the initial theString is
large (> 100K) and there are 100's of these strings.
You don't need a degree in applied meta physics to see where this is
going. It's not the fault of autorelease I know, it's the fault on
inexperienced developers or people that blindly follow rules.
The underlying problem is that it makes the above method data
dependent without really drawing much attention to this fact. I
actually had a bug that was caused by this. I worked on an iPad app
for an International Newspaper. The App was working ok, until one day
it crashed a 5 AM when the new edition was published and the iPad
client software downloaded and processed it. When it got to the
sports section a method similar to the above (although a lot more
complex with a LOT more autorealsed objects) crashed. I got in a 6 AM
and it took me a good while to figure out what was wrong. On that
particular day, the paper published the football (soccer) league
tables for the whole of the UK. Apart from there being a loads of
data, it was also heavily attrubuted, bold, italics, colours etc.
Well it was too much for the method and when it had built up around
80 to 100 MB of useless autoreleased strings, it crashed!!
There are loads of other problems I come across as a side effect of
junior (and sometimes senior) developers using autorelease, but I
think the above described above was the worst.
That's why I say it's "evil" and I avoid it with a vengeance. So why
do you think it's a force for good?
Besides all this, is it really so hard to add:
[xxxx release];
It's less typing than autorelease anyway!!!
All the Best
Dave
_______________________________________________
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