On 2011-10-09, at 05:05, Quincey Morris wrote:

>> What am I doing wrong? Shouldn't the instance created using 
>> dataWithBytesNoCopy:length:freeWhenDone simply hold the same bytes as 
>> the originally provided ones? 
> 
> Presumably you're using 'dataWithBytesNoCopy:length:freeWhenDone:NO', since 
> 'dataWithBytesNoCopy:length:freeWhenDone:YES' would be invalid in the 
> scenario you describe. 

Right.

> I'd guess that, with the 'NO' parameter, NSMutableData copies the data 
> anyway. Mutating the data would become treacherous if the underlying memory 
> doesn't belong to the NSMutableData object that's trying to mutate it.

That would explain, although the "NoCopy" is in that case moot then.

> So, really all you could do is change individual bytes, and you scarcely need 
> subsidiary NSMutableData objects for that -- simple C pointers would do. 
> (Note, however, that you'd be using interior pointers, which would open you 
> up to a range of possible memory management issues, depending on which memory 
> model you're using.)

I see. And agree.

> What are you trying to get the subsidiary NSMutableData objects to do for you 
> that C pointers won't?

No - I mean I can do all those things I need to do by laying a set of structs 
over the array of bytes I receive within the original NSMutableData instance. 
But what I tried to achieve was to do it somewhat more "OO", although sharing 
the payload between various instances seems to be contradicting it ;-) And I 
also wanted to minimise the overhead of passing and copying large amounts of 
data around in order to do the manipulations, while at the end having a need to 
reconstruct the original stream (file format) from multiple objects.

Regards,

-- 
SD!_______________________________________________

Cocoa-dev mailing list ([email protected])

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to