It lives only in the 'platform' layer of my code. Grudgingly because Apple enforce it.
It could be worse... they could have pulled a Google and used Java - then held back the tools they develop e.g. the Java VM because they are 'dangerous' and suggest that using native code is 'bad' if it is just for performance or cross-platform reasons.
At least the interoperability with sane programming languages in Objective-C is excellent.
I'd point out the vast majority of memory management issues I have is when using someone's refcounting or gc scheme. new and delete are exactly what i want all of the time. i like to tell the machine what to do and i have developed non-trivial software without leaks /before testing for leaks/ because once you have some practice with new and delete it becomes easy and you will never look back...
As a mechanism for broadcasting information throughout an app NSNotificationCenter is slower, more complicated and (apparently) more dangerous than my hand rolled code. That should be shocking and its counter to the common idea that 3rd party and especially OS libraries should be better... there are a number of cases where they measurably aren't.
(The overhead of the objective C message mechanism - or even the RTTI mechanism which is a small part of that, exceeds that of adding or reading something from a well implemented threadsafe data structure (which is the first step to either of these things in most cases))
Any explanation for the downvotes? I concede the value of rapid application development, but objective-c itself doesn't provide this at all - rather the libraries like UIKit or Cocoa coupled with the Xcode development environment do this.
Objective-C is measurably bad for my code. I have reams of data to support this... and its all trivially reproducable.
when i mention the slowness of the message mechanism this is both by design of Objective-C (for runtime features) and very measurable. this is why, for example, NSArray becomes prohibitively slow when you want to iterate across 1000s of members.
Objective-C is nice, but its slow by design, and this rules it out in a concrete way for a lot of the work I've done.
Its sad when optimisation comes down to 'knowing better than the compiler' only because of language constraints. (even C has this problem with struct layout for example - its just prevalent when using Objective-C/Cocoa (Touch))
yes, basically. i don't like paying the cost at runtime for a lot of things... NSArray is very useful for instance, but I can't use it for any serious amount of data I want to process in a frame. this comes down to the design of the language implementation not caring about performance. its not so much a tradeoff as 'for performance reasons I can not use Objective-C'
i also don't like the ref counting. when given a choice i would rather do my own allocations.
It lives only in the 'platform' layer of my code. Grudgingly because Apple enforce it.
It could be worse... they could have pulled a Google and used Java - then held back the tools they develop e.g. the Java VM because they are 'dangerous' and suggest that using native code is 'bad' if it is just for performance or cross-platform reasons.
At least the interoperability with sane programming languages in Objective-C is excellent.
I'd point out the vast majority of memory management issues I have is when using someone's refcounting or gc scheme. new and delete are exactly what i want all of the time. i like to tell the machine what to do and i have developed non-trivial software without leaks /before testing for leaks/ because once you have some practice with new and delete it becomes easy and you will never look back...
As a mechanism for broadcasting information throughout an app NSNotificationCenter is slower, more complicated and (apparently) more dangerous than my hand rolled code. That should be shocking and its counter to the common idea that 3rd party and especially OS libraries should be better... there are a number of cases where they measurably aren't.
(The overhead of the objective C message mechanism - or even the RTTI mechanism which is a small part of that, exceeds that of adding or reading something from a well implemented threadsafe data structure (which is the first step to either of these things in most cases))