>>>>>> This is why I was leaning towards NSData. Actually, the real
>>> benefit is with NSMutableData. Mallocing an array of char like
>>> NSData would is trivial, but dealing with resizing is more
>>> difficult. NSMutableData does it for us and deals with memory
>>> issues. In addition, because it is a class cluster (sorry, the c
>>> word!), it might be (or will be) optimized for different sizes of
>>> data. Also, it is easy to write/read files, but also send data
>>> over the network... Finally, it is Core Data compatible. The
>>> bottom line is: if we malloc our own char[], we might end up
>>> creating NSData object anyway. Getting the pointer to the array of
>>> bytes is trivial: [myData bytes] or [myData mutableBytes].
>>>>>>>>>> But I guess for the data operations we will still need the nitty
>> gritty C calls, including friendly stringpointers.
>>
I'm all for NSData, since I know how to use that ;). Next question - we're
already using unichar's, which are 2 bytes - is that what we intend to stuff
in the data, or should we think of recasting to unsigned chars? The second
would probably greatly increase the efficiency of the code and make a lot
more C code available to us, but we'd need to revamp a bunch of the classes.
JT
_______________________________________________
This mind intentionally left blank