Nikolaus,
On Fri, Nov 22, 2019 at 5:51 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> Am 22.11.2019 um 11:20 schrieb Andreas Fink <afink@list.fink.org>:
>> On 22 Nov 2019, at 09:08, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>> Am 22.11.2019 um 08:40 schrieb David Chisnall <gnustep@theravensnest.org>:
>>>
>>> On 22 Nov 2019, at 05:31, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>>
>>>> And the first thing I turn off in a
>>>> new Xcode project is ARC.
>>>
>>> Why? ARC generates smaller code, faster code, and code that is more likely to be correct.
>>
>> I never had a problem with any of those three. Code correctness is rarely a retain/release problem but the algorithm.
>> So it solves only a small percentage of the coding problems I do face.
I once spent 3 days tracking down a memory issue I found in an iOS application I wrote for a client. Granted I got paid for this, but it was by no means the first or last memory issue with the app. The application was very complex and all of this would never have been an issue if ARC had been invented at the time... but this was early days. ARC has made things easier for me without a doubt. I understand memory management, but it can get complex at times. If the compiler can figure it out I prefer to let it do the work.
> Then you have not done any big projects.
I have summed up wc -l on all of my *.m files and the sum is 1434555 in 5656 files.
Not all are originally from me and there may be duplicates.
Doesn't seem to be big projects, indeed.
Still most coding problems are that the algorithm doesn't do what it should do (e.g. wrong loop counters, wrong break logic, wrong understanding of the requirements etc.).
Indeed, but wouldn't it be best if you could SIMPLY focus on the algorithm? Any time spent figuring out or even coding memory management is time NOT spent coding the algorithm.
>
> Even though my code is well designed in terms of ownership of objects, I still managed to every once in a while shoot myself into the foot and have to track down memory leaks forever or random crashes.
Each time I have such a random crash the log tells me that a deallocated object is referenced and then it is usually easy to fix. But it rarely happens if you know the rules who owns the object and you do not randomly release something you don't own. Leaks are a little harder to detect but can also be avoided if ownership is well defined. Basic rule: you only (auto)release what you create (by alloc or copy) or what you store&retain to be used after ARP cleanup.
The above applies here. It's always easier to allow the compiler to figure it out for you.
Sometimes it is also possible to set up unit tests checking -releaseCount.
> Switching to ARC made all these problems go away. No more use after free, no more keeping objects around after no one uses it anymore etc.
> You don't have to think of releasing stuff if you are in the middle of a long routine and throw an exception or call return.
It's important to remember that it is possible to screw things up with ARC since it uses the @property declaration to determine how to manage memory.
Just use autorelease before risking the exception or return...
It's not ALWAYS so simple.
> This is a major advantage of Objc2.0.
> I must admit it took me a while to get used to though. But at the end it paid off a lot.
Well, to be precise: ARC could also be done with ObjC 1.0 as far as I see. There is IMHO no special syntax for ARC. You just remove all retain/release/autorelease from the code and the compiler is clever enough to magically make it still work.
There is special syntax for ARC, though it may not be immediately obvious. The @property settings (retain, assign, strong, etc) are used by ARC to hint the compiler on how to handle the memory allocation.
So in summary, ARC alone isn't sufficiently helpful for my work to switch to ObjC 2.0 and no longer use gcc.
Certainly not ARC alone, since the obvious solution is to implement it yourself. What concerns me most is that there are features, namely blocks, which cannot be duplicated on GCC. The API is becoming MORE and MORE dependent on blocks for completion handlers. The more features which are added to ObjC (whose reference implementation we should consider as the one implemented by Clang) the further GCC will fall behind and the more we will have to introduce ugly kludges.
Yours, GC
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/