On Jul 15, 2014, at 10:20 AM, Jens Alfke wrote:
>
>
>> On Jul 15, 2014, at 9:50 AM, Carl Hoefs
>> wrote:
>>
>> Awesome! I had been wondering if this concept existed in Cocoa, didn't see
>> it in the NSData docs. It's sort of like using iovec structs with
>> readv/writev for sockets. I would
On Jul 15, 2014, at 9:50 AM, Carl Hoefs wrote:
> Awesome! I had been wondering if this concept existed in Cocoa, didn't see it
> in the NSData docs. It's sort of like using iovec structs with readv/writev
> for sockets. I would primarily use the dispatch_data_create_map() function,
> right? L
On Jul 15, 2014, at 1:45 AM, Mike Abdullah wrote:
>
> Another possibility is to use dispatch_data. Rather than copy bytes around to
> assemble them into a contiguous buffer, your use case might be just as well
> suited to dispatch_data’s approach of tying together various non-contiguous
> buff
On 15 Jul 2014, at 00:32, Jens Alfke wrote:
>
> On Jul 14, 2014, at 1:07 PM, Carl Hoefs
> wrote:
>
>>modifiableData = [ NSMutableData dataWithData: [ external call that gives
>> me an NSData ] ];
>
> It’s shorter and more idiomatic to just say
> modifiableData = [external mutable
On 15 Jul 2014, at 4:54 am, Jens Alfke wrote:
> The equivalent function in the ‘classic’ Mac OS had the very appropriate name
> of Munger( ) since it would munge bytes around in a heap block. Knowing how
> to use Munger was a sign of geek cred in the old (80s-90s) Mac dev community.
My god,
On Jul 14, 2014, at 1:07 PM, Carl Hoefs wrote:
> modifiableData = [ NSMutableData dataWithData: [ external call that gives
> me an NSData ] ];
It’s shorter and more idiomatic to just say
modifiableData = [external mutableCopy];
(plus an autorelease if you’re not using ARC)
> Will
On Jul 14, 2014, at 12:57 PM, "Gary L. Wade"
wrote:
> where you're creating the object
On Jul 14, 2014, at 12:53 PM, Jens Alfke wrote:
> If you’re the one creating the NSData object in the first place, can you
> create it as an NSMutableData?
Certainly that makes sense enough, just hoping
The reason you can't do exactly what you're asking is because there may be
other owners of the immutable object. Since NSMutableData is a subclass of
NSData, you should ask yourself where you're creating the object and try
creating it from the start as mutable, and also if there are owners of th
On Jul 14, 2014, at 12:15 PM, Carl Hoefs wrote:
> Okay, 1 last question on this. Is there a way to promote-in-place an NSData
> object into an NSMutableData object? -becomeMutable or some such? I'm trying
> to avoid copying megabytes of data/sec if it's avoidable.
Nope. Part of the contract
On Jul 14, 2014, at 11:54 AM, Jens Alfke wrote:
>
> On Jul 14, 2014, at 11:48 AM, Carl Hoefs
> wrote:
>
>> Yes, I guess it's the semantics that threw me. I was attempting to
>> "insertBytesInRange" not "replaceBytesInRange", so I had it in my mind that
>> the one couldn't do the other. But
On Jul 14, 2014, at 11:48 AM, Carl Hoefs wrote:
> Yes, I guess it's the semantics that threw me. I was attempting to
> "insertBytesInRange" not "replaceBytesInRange", so I had it in my mind that
> the one couldn't do the other. But that's the whole purpose of the NSRange.
> Very cool.
The eq
On Jul 14, 2014, at 11:35 AM, Ben Kennedy wrote:
> On 14 Jul 2014, at 11:30 am, Carl Hoefs
> wrote:
>
>>> [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr
>>> length:1024];
>>
>> Wow, that's damn clever! My thinking is so clunky. It never would have
>> occurred to me tha
On 14 Jul 2014, at 11:30 am, Carl Hoefs wrote:
>> [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr
>> length:1024];
>
> Wow, that's damn clever! My thinking is so clunky. It never would have
> occurred to me that NSMutableData could expand (0,0) into (0,1024) out of
> thin
On Jul 14, 2014, at 11:22 AM, Mike Abdullah wrote:
> [bigMData replaceBytesInRange:NSMakeRange(0,0)
>withBytes:newBytesPtr
> length:1024];
On Jul 14, 2014, at 11:23 AM, Ben Kennedy wrote:
> [bigMData replaceBytesInRan
On 14 Jul 2014, at 11:12 am, Carl Hoefs wrote:
> Okay, now if I want to insert 1024 bytes of new data at the beginning of a
> populated NSMutableArray, is there a better way than this:
Sure; why not just do [bigMData replaceBytesInRange:NSMakeRange(0,0)
withBytes:newBytesPtr length:1024]; ...
On 14 Jul 2014, at 19:12, Carl Hoefs wrote:
> Okay, now if I want to insert 1024 bytes of new data at the beginning of a
> populated NSMutableArray, is there a better way than this:
Yes.
[bigMData replaceBytesInRange:NSMakeRange(0,0)
withBytes:newBytesPtr
Okay, now if I want to insert 1024 bytes of new data at the beginning of a
populated NSMutableArray, is there a better way than this:
NSMutableData *bigMData = ... // (approx 1MB of data);
int origlength = bigMData.length;
uint8_t *newBytesPtr = ...
. . .
// Shift contents ove
On Saturday, July 12, 2014, Carl Hoefs
wrote:
> On Jul 12, 2014, at 1:51 PM, Matt Gough > wrote:
>
> > [bigData replaceBytesInRange:NSMakeRange(0, 1024) withBytes:NULL
> length:0];
>
> Wow, I would never have thought to do that! Works perfectly!
You could also declare a category on NSMutableDa
On Jul 12, 2014, at 1:51 PM, Matt Gough wrote:
> [bigData replaceBytesInRange:NSMakeRange(0, 1024) withBytes:NULL length:0];
Wow, I would never have thought to do that! Works perfectly!
Thx,
-Carl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com
don’t you just want:
[bigData replaceBytesInRange:NSMakeRange(0, 1024) withBytes:NULL length:0];
??
I am sure NSMutableData is well optimized for shunting its contents around
internally.
Matt
On 12 Jul 2014, at 20:36, Carl Hoefs wrote:
> Basically what I would like is an NSMutableData meth
Basically what I would like is an NSMutableData method like this:
- (void)resetDataRangeTo:(NSRange)range
Parameters
range
The range within the contents of the receiver to be considered the new contents.
But, since that doesn't exist yet, is it safe to "shift" the contents in place
of an NSMut
21 matches
Mail list logo
