Re:On Apple's Love Affair with Swift
by 0x0 on Saturday August 11, 2018 @09:25AM
(#17739579)
ARC in objective-c has almost fully solved this issue in practice.
[ Parent
| on HN ]
Nope. I still found many ways to crash my objective C apps while using ARC. Because Swift is memory safe I no longer have to give up days or weeks of my life tracking down obscure bugs caused by overwriting memory I should not have.
Re:On Apple's Love Affair with Swift
by gurkendoktor on Sunday August 12, 2018 @05:33AM
(#17743665)
Could you please give some concrete examples of how memory corruption has affected you in modern Objective-C? NSArray has range checks, delegates can't dangle anymore because they're weak references now. I think that leaves interaction with C APIs, but don't Swift users have to deal with UnsafeMutablePointer to use them - which isn't memory safe either?
Re:On Apple's Love Affair with Swift
by jakobegger on Sunday August 12, 2018 @09:53AM
(#17744347)
The easiest way to cause memory issues is to access mutable collections from multiple threads. I really wish NSMutableArray and friends were thread safe...
Unfortunately, Swift doesn't fix that AFAIK.
No no no. That is a one-way trip to hell. There is no ”good for all threading scenarios” thread safe mutable array design.
I’ve debugged too much java code where the programmers thought that ”thread-safe” meant ”no need to think about threading issues”.
Thanks for having the patience to put all these Obj-C myths to rest.
The Obj-C community (or what's left of it) is trying to make a martyr of an error-prone, cumbersome programming language.
Try to use ARC with C APIs.
That's like saying try to use Java JNI with C APIs. Think of
direct C API access in Objective-C a bonus, not a design pattern :)
Completly different, ARC only works with APIs that follow Cocoa retain/release patterns, which aren't the only APIs that one needs to use, e.g. CoreGraphics.
And unlike JNI they aren't protected by a VM wall.