3 ms·
After covering reference counting in my first reply, I want to tackle the pointer arithmetic question here. Pointer arithmetic specifically, or direct memory a
by flatline3 14y ago
After covering reference counting in my first reply, I want to tackle the pointer arithmetic question here.
Pointer arithmetic specifically, or direct memory access more generally, is bug prone and dangerous. Its valuable primarily in terms of performance, and is a terrible idea in terms of correctness and security.
In runtime-managed languages, efficient access to memory buffers is achieved by exposing an array type, and then performing basic bounds checking on array access. This is efficient enough for most purposes, is essentially what you achieve by using NSData, and is generally implemented in a way that is vastly more efficient than NSData.
Direct memory access in straight C will be faster, but it's also enormously error prone, and something I avoid if at all possible when writing ObjC or even straight C.
While there's no discounting the performance value of being able to operate at this level (or write straight assembly), it's rarely a useful thing to do when writing most application-level code, especially when weighed against the propensity for failure.
All managed languages allow for extension through C for the cases where low-level performance is required. ObjC has the easiest means of working with C, but that should be balanced against the fact nearly all of ObjC's ugly warts and pain points derive from being a strict C superset.