Re: dataWithBytesNoCopy:length:freeWhenDone
Re: dataWithBytesNoCopy:length:freeWhenDone
- Subject: Re: dataWithBytesNoCopy:length:freeWhenDone
- From: email@hidden
- Date: Sun, 09 Oct 2011 14:44:06 +0200
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@hidden)
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:
This email sent to email@hidden