8 ms·

Avoiding dangling pointers requires a bit of discipline in pre-ARC Objective-C and C++, but now that we have ARC, isn't ObjC pretty much as safe as Swift? (Unle

Avoiding dangling pointers requires a bit of discipline in pre-ARC Objective-C and C++, but now that we have ARC, isn't ObjC pretty much as safe as Swift? (Unless you explicitly use "assign" properties, of course.)

LeoNatan25 9y ago
Apparently, the elegance of ObjC's handling of nil objects is considered also "unsafe" these days. I disagree with that specifically.
- favorited 9y ago
  Objective-C's solution had its downsides, though. The classic `[firstName stringByAppendingString:lastName];` being fine when `firstName` is nil, but not if `lastName` is (though it doesn't always crash if `lastName` is nil – it's fine if `firstName is also nil!). Or how `[myObject isEqualTo:myObject]` returns false if `myObject` is nil. Or how adding a nil object to an NSArray doesn't crash (but is likely a bug!) when calling `arrayWithObjects:`, but does crash when it's an array literal. These aren't world-ending problems, and you learn the rules easily enough, but it's like Objective-C only solved 1/2 of the problem. Then there's the really strange corner cases, like how sending a message to nil was undefined behavior: - when expecting a returned struct, before Apple switched to LLVM 3.0 (would vary depending on the platform's ABI, as well as the size of the struct) - when expecting a returned floating-point value on PPC <= 10.4, - when expecting a returned `long long` on PPC (it happened to return `(long)selector`) For the record, I always loved how Objective-C handles this – I definitely preferred it to Java, Ruby, etc. where you're constantly checking for null or catching NPEs. But I like Swift's solution even more. I no longer have to remember about which parameters are nullable, or sanitize my inputs with `NSParameterAssert`s, etc. Edit: also, `NSNull`. Ugh.
pjmlp 9y ago
No because there is the whole C part of Objective-C, including UB. So unless there is some validation of 100% of the code writen by the team and third party libraries, it is impossible to ensure there aren't C style coding tricks being used. Also ARC only applies to Cocoa like classes, there is no bounds checking, implicit casts are like in C, C style strings are still used in many APIs, and this are just a few examples of unsafety.

LeoNatan25 9y ago

Apparently, the elegance of ObjC's handling of nil objects is considered also "unsafe" these days. I disagree with that specifically.

favorited 9y ago
Objective-C's solution had its downsides, though. The classic `[firstName stringByAppendingString:lastName];` being fine when `firstName` is nil, but not if `lastName` is (though it doesn't always crash if `lastName` is nil – it's fine if `firstName is also nil!). Or how `[myObject isEqualTo:myObject]` returns false if `myObject` is nil. Or how adding a nil object to an NSArray doesn't crash (but is likely a bug!) when calling `arrayWithObjects:`, but does crash when it's an array literal. These aren't world-ending problems, and you learn the rules easily enough, but it's like Objective-C only solved 1/2 of the problem. Then there's the really strange corner cases, like how sending a message to nil was undefined behavior: - when expecting a returned struct, before Apple switched to LLVM 3.0 (would vary depending on the platform's ABI, as well as the size of the struct) - when expecting a returned floating-point value on PPC <= 10.4, - when expecting a returned `long long` on PPC (it happened to return `(long)selector`) For the record, I always loved how Objective-C handles this – I definitely preferred it to Java, Ruby, etc. where you're constantly checking for null or catching NPEs. But I like Swift's solution even more. I no longer have to remember about which parameters are nullable, or sanitize my inputs with `NSParameterAssert`s, etc. Edit: also, `NSNull`. Ugh.

pjmlp 9y ago

No because there is the whole C part of Objective-C, including UB. So unless there is some validation of 100% of the code writen by the team and third party libraries, it is impossible to ensure there aren't C style coding tricks being used. Also ARC only applies to Cocoa like classes, there is no bounds checking, implicit casts are like in C, C style strings are still used in many APIs, and this are just a few examples of unsafety.