I m pretty new to the Objective-C world and I have a long history with .net/C# so naturally I m inclined to use my C# wits.
Now here s the question: I feel really inclined to create some type of simple Objective-C collection to hold primitive types because I do not like the whole concept of wrapping a primitive type into an object (namely NSNumber) and then adding that to a collection such as NSArray.
The thing is, is that I completely understand that NSArray s only operate on objects. However it just seams really dumb to me that we are forced to work with boxed primitives just because no collection exists to work on primitive Integers for instance.
So the C# guys will know what I m talking about in the old days with .net. Generally you d either use a simple array or an ArrayList back when generics weren t around yet. The ArrayList essentially forced you to box your primitive types but it actually did it behind the scenes and you paid a dear cost for it (in terms of performance.)
If you couldn t deal with the performance cost then you rolled your own custom collection or eventually used generics when they came out.
Now in the Objective-C world it seams we are forced to deal with this problem again but it s like the Apple developers don t really care, or it s just not a big deal or what.
So my question is: What is the recommend practice here? Should I try to build my own custom Objective-C collections for holding an NSInteger for example? Or should I just use a native C array as fellow coder Memo suggests in this blog post: NSArray vs. C Array performance
Or do I just stick with using Apple s built-in collections and bite the bullet. It seams that the performance characteristics explained by Memo are worth considering when building performance critical apps.
This post was a mouthful but I had to get it off my chest.