Le 14 mars 2013 à 11:12, Richard Heard <heard...@gmail.com> a écrit :
> Your logic is clearly flawed. This only seems to replace occurrences of $
> with the word DOLLAR.
>
> Also, if you are dealing with large strings, you could always use one of the
> below idioms to reduce memory pressure.
>
>
> @autoreleasepool { }
> or
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> [pool drain];
>
> -R
>
Or simply work on a mutable string when you plan to mutate it.
> On 13/03/2013, at 3:07:30 AM, Dave <d...@looktowindward.com> wrote:
>
>>
>> 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 <d...@looktowindward.com> 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 (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:
>> https://lists.apple.com/mailman/options/cocoa-dev/heardrwt%40gmail.com
>>
>> This email sent to heard...@gmail.com
>
> _______________________________________________
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
>
> This email sent to devli...@shadowlab.org
-- Jean-Daniel
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
